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

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2011-04-21 13:05:54 UTC ---
On Thu, 21 Apr 2011, rakdver at kam dot mff.cuni.cz wrote:

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

What we lose when we treat them as opaque is disambiguating the load of i
in

int i;
int foo (int *p) { i = 0; *(p + 4) = 1; return i; }

where *(p + 4) is MEM[p, 16] where we see that p + 16 != &i for any
valid (in the C sense) pointer p.

That would indeed be not so nice.

Richard.