[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

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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).