https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 8 Mar 2018, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84658 > > --- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #16) > > Hum, isn't the bug INVALID then? Shouldn't we restrict > > -fmerge-all-constants > > No. > > > to not address-taken variables to not make the option useless? > > -fmerge-all-constants is an extension where the addresses of the constant > variables may be the same even if without the option they would need to be > guaranteed to be different. That is the whole point of the option, many > people > just don't care about it and care more about .rodata size, so they have an > option to tell the compiler about it. That's not really an answer to the question ... But anyway, we have precedence in points-to-set editing which we do during RTL expansion to reflect variable coalescing. So ... a different approach for fixing would be if ICF would keep a) a global bitmap of all DECL_UID that took part in any merging operation b) a mapping of merged DECL_UID to prevailing DECL_UID (which is also the DECL_PT_UID of the merged ones) then during IPA ICF transform phase do FOR_EACH_DEFINED_FUNCTION (...) { FOR_EACH_SSA_NAME_FN (..., name) if (POINTER_TYPE_P (TREE_TYPE (name)) && SSA_NAME_PTR_INFO (name)) fixup_pt_set (&SSA_NAME_PTR_INFO (name)->pt); fixup_pt_set (fn->gimple_df->escaped); /* The above get's us to 99% I guess, at least catching the address compares. Below also gets us aliasing correct but as said we're giving leeway to the situation with readonly vars anyway, so ... */ FOR_EACH_BB_FN (...) for (each-stmt) if (is_gimple_call (...)) { fixup_pt_set (gimple_call_use_set (call)); fixup_pt_set (gimple_call_clobber_set (call)); } } and fixup_pt_set essentially doing EXECUTE_IF_AND_IN_BITMAP (pt->vars, bitmap-of-merged-decls, 0, i, bi) bitmap_set_bit (pt->vars, *merged_uid_to_pt_uid->get (i)); that would be a "real" fix, also allowing the forthcoming pointer comparison optimization using two pointers (and thus two points-to sets). > > I presume -fmerge-all-constants pre-dates ICF? > > Yes, by far. -fmerge-all-constants is from 2001, ICF from 2014.
