This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
- From: "rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 05 Mar 2015 09:42:34 +0000
- Subject: [Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses
- Auto-submitted: auto-generated
- References: <bug-65270-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> ---
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 ...
> 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.