[Bug tree-optimization/49279] [4.5/4.6/4.7 Regression] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2011-10-05 09:40:58 UTC ---
On Wed, 5 Oct 2011, jakub at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
> 
> --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-05 09:04:59 UTC ---
> Created attachment 25419
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25419
> patch
> 
> An incomplete patch to avoid those casts from the IL.
> We'd need to adjust SRA to add casts if a restrict field is scalarized and a
> non-restrict pointer is stored into it.  It fixes this short testcase though.
> It is not enough though, because FRE/PRE can see through the field store
> and will create undesirable restrict casts:
>   t_3->p = q_4(D);
> ...
>   D.2099_6 = t_3->p;
> becomes
>   t_3->p = q_4(D);
> ...
>   D.2099_6 = (int * restrict) q_4(D);
> during fre1 (in this case it doesn't matter, as for s.p FRE can't see through
> the pointer and thus it doesn't have a restrict tag).  So, either FRE/PRE (and
> whatever else) would need to give up on seeing through in these non-restrict ->
> restrict field cases, or it would be better instead of avoiding these casts
> make non-restrict -> restrict casts from user code explicit (e.g. some
> different kind of gimple unary assignment), treat them more carefully during
> optimizations (yes, it would prevent some optimizations, but hopefully restrict
> is used only where it actually can give more improvements from successful
> disambiguation) and only handle those as CAST_RESTRICT and not random other
> !TYPE_RESTRICT -> TYPE_RESTRICT conversions in the IL which are there just for
> IL consistency
> (we could even make such non-special !restrict -> restrict conversions
> useless).

I think rather than trying to remove those casts from the IL we should
think if preserving restrict optimizations for inlining is really
important (which is what the cast handling is for).  The cast handling,
compared to the existing handling of arguments and global vars, is
really sensitive to optimizations to be 'correct' (see the other PR
where we inline a restrict argument function twice and assign
different restrict tags during PTA to the two copies and do
wrong cross inlined-body optimizations).

So, for correctness we should consider removing the cast handling.
(My proposed fix for the other PR sofar was to assign a fake tag
to every pointer so propagation can see the two pointers (with
different restrict tag) are still based on each other).

Richard.