https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
--- Comment #24 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #22) > On Thu, 5 Mar 2015, hubicka at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 > > > > --- Comment #18 from Jan Hubicka <hubicka at gcc dot gnu.org> --- > > Here is summary of my current understanding of remaining issues from my last > > weekend's audit. > > > > ICF specific: > > - ipa-icf-gimple.c needs to match dependence analysis > > Richard has propsed a patch for it, so I hope he will commit it tomorrow. > > - restrict flag may need to be matched when considering two references > > to variables being equal. > > Here I am waiting for Richards comment. I would propose matching > > restricts > > in compare_cgraph_references same way as we now compare vtables. > > Works for me. Having a testcase that shows the issue would be > nice though (I don't get the variables merged it seems, or somehow > the initializers prevail even on the aliases?) > > > non-ICF specific wrong codes > > - tree-vectorizer is picking up wrong alignment > > Fixed. > > > - fold-const.c's operands_equal_p probably needs same treatment for > > comparing mem-ref as ipa-icf-gimple has. I think in all cases one can > > construct testcase where tree-tail-merge would produce same incorrect > > merging as ipa-icf does. > > No, it simply means that you can't use operand_equal_p (value equivalence) > if you want semantic equivalence in a greater scope. This is why I > asked for the ICF and tail-merging stmt compare code to be unified ... Still on my radar, few months ago, I was able to come up with prototype that was at least as good as current implementation. It can be adopted for next release. > > > stuff that can wait for next stage1 > > - ipa-pure-const is probably wrong to check TYPE_NEEDS_CONSTRUCTION flag > > (something to fix for next stage1) > > - expand_builtin_classify_type can probably be dropped, because > > fold_classify_type prevails.
