[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" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #11 from rakdver at kam dot mff.cuni.cz <rakdver at kam dot mff.cuni.cz> 2011-04-21 13:34:29 UTC ---
> > > 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.

what about always interpreting the computations in the type of the base of
MEM_REF
(allowing non-pointers as the base)?  So both of the following forms would be
valid:

1)
int *p;

MEM[p + 16]
which is equivalent to *(p POINTER_PLUS 16)

2)
int *p;
unsigned v = (unsigned) p;

MEM[v + 16]
equivalent to *(int *) (v + 16)

The form 1) would be default, and contains the information needed by alias
analysis.
The form 2) would only be generated by optimizations that are unable to decide
whether
  the pointer arithmetics form is valid (ivopts), and would be treated as
opaque by
  alias analysis.