This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug ipa/65270] [5 regression] ICF needs to match TYPE attributes on memory accesses


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]