[Bug tree-optimization/48702] [4.6/4.7 Regression] optimization regression with gcc-4.6 on x86_64-unknown-linux-gnu

[rakdver at kam dot mff.cuni.cz]

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

--- Comment #9 from rakdver at kam dot mff.cuni.cz <rakdver at kam dot mff.cuni.cz> 2011-04-21 12:56:20 UTC ---
>   ivtmp.25_24 = (long unsigned int) &array;
>   array.26_26 = (long unsigned int) &array;
>   D.2769_27 = array.26_26 + 0x0fffffffffffffff0;
> 
> <bb 3>:
>   # ans_21 = PHI <ans_16(4), 0(2)>
>   # ivtmp.25_20 = PHI <ivtmp.25_19(4), ivtmp.25_24(2)>
>   D.2741_10 = ans_21 * 2;
>   D.2767_25 = (void *) ivtmp.25_20;
>   D.2737_15 = MEM[(int *)D.2767_25 + 12B];
>   ans_16 = D.2741_10 + D.2737_15;
>   ivtmp.25_19 = ivtmp.25_20 - 4;
>   if (ivtmp.25_19 != D.2769_27)
>     goto <bb 4>;
>   else
>     goto <bb 5>;
> 
> <bb 4>:
>   goto <bb 3>;

So the computation of the induction variable is performed in (long unsigned
int),
which should be safe.

> I am somewhat sympathetic to treating indirect (TARGET_)MEM_REFs as opaque,
> only looking at the final pointer that is dereferenced, not at the
> pieces of the address computation.  We'd retain the case where two
> such derefrences differ only in a constant offset.
> 
> I don't think that any pass interprets the address computation that is
> implicit in a memory refrence in any way at the moment.

We definitely should decide on and document the precise semantics of
(TARGET_)MEM_REFs.
One possibility is to give no guarantees on the computations (i.e., treat them
as opaque);
this is easy for ivopts, but possibly removes some useful information (at least
for MEM_REFs,
I would not do that).  On the other hand, if we decide to enforce the
restrictions as for
the pointer arithmetics, we should also say e.g. in what way are the parts of
the address
computation in TARGET_MEM_REFs associated, as that may make a difference.