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.
