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.
