<font size=2 face="sans-serif">Thanks for all the discussions. Can I draw
following conclusions from them:</font>
<br><font size=2 face="sans-serif">1. We cannot set NoWrap flag for
x+2k only based on the loop induction </font>
<br><font size=2 face="sans-serif">2. If we know x+2k is an inbound array
GEP, the NoWrap flag can be set true according to the C standard</font>
<br>
<br><font size=2 face="sans-serif">Therefore, should I make the following
change in LoopAccessAnalysis.cpp:543:</font>
<br>
<br>
<br><font size=2 face="sans-serif">original code:</font>
<br>
<br><font size=2 face="sans-serif"> bool IsInBoundsGEP = isInBoundsGep(Ptr);</font>
<br><font size=2 face="sans-serif"> bool IsNoWrapAddRec = AR->getNoWrapFlags(SCEV::NoWrapMask);</font>
<br>
<br><font size=2 face="sans-serif">to </font>
<br>
<br><font size=2 face="sans-serif"> bool IsInBoundsGEP = isInBoundsGep(Ptr);</font>
<br><font size=2 face="sans-serif"> bool IsNoWrapAddRec = AR->getNoWrapFlags(SCEV::NoWrapMask)
|| IsInBoundsGEP;</font>
<br>
<br><font size=2 face="sans-serif">Tong</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Adam Nemet <anemet@apple.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Sanjoy Das <sanjoy@playingwithpointers.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">Tong Chen/Watson/IBM@IBMUS,
Andrew Trick <atrick@apple.com>, LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>,
Arnold <aschwaighofer@apple.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/11/2015 04:40 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [LLVMdev]
Question about NoWrap flag for SCEVAddRecExpr</font>
<br>
<hr noshade>
<br>
<br>
<br>
<br><font size=3>On Jun 11, 2015, at 12:48 AM, Sanjoy Das <</font><a href=mailto:sanjoy@playingwithpointers.com><font size=3 color=blue><u>sanjoy@playingwithpointers.com</u></font></a><font size=3>>
wrote:</font>
<br>
<br><font size=1 face="Helvetica">On Thu, Jun 11, 2015 at 12:02 AM, Adam
Nemet <</font><a href=mailto:anemet@apple.com><font size=1 color=blue face="Helvetica"><u>anemet@apple.com</u></font></a><font size=1 face="Helvetica">>
wrote:</font>
<br>
<br><font size=1 face="Helvetica">On Jun 10, 2015, at 11:44 PM, Sanjoy
Das <</font><a href=mailto:sanjoy@playingwithpointers.com><font size=1 color=blue face="Helvetica"><u>sanjoy@playingwithpointers.com</u></font></a><font size=1 face="Helvetica">>
wrote:<br>
</font>
<br><font size=1 face="Helvetica">Base is treated as unsigned so 0xff…ff
+ 1 would be 0x100…00</font>
<br><font size=1 face="Helvetica"><br>
This is the part I was missing, thanks for pointing out the FAQ. So<br>
the infinitely precise address computed by a GEP is<br>
<br>
zext(Base) + sext(Idx0) + sext(Idx1) … ?</font>
<br><font size=1 face="Helvetica"><br>
Yes, that is the way I read it.<br>
</font>
<br><font size=1 face="Helvetica">0x100…00 which would be out of bounds
(sort of).</font>
<br><font size=1 face="Helvetica"><br>
Does this mean, for C++ programs of the form,<br>
<br>
for (int *I = array, *E = array + size; I != E; ++I)<br>
...<br>
<br>
the memory allocator has to guarantee that array cannot span<br>
[0xff..fffff-31,0xff..fffff] (both inclusive) with size == 32?</font>
<br><font size=1 face="Helvetica"><br>
I think so. Address 0 cannot be dereferenced, so you can’t have
a valid object spanning across address 0.</font>
<br><font size=1 face="Helvetica"><br>
I the example I meant to give, [0xff..fffff-31,0xff..fffff] == [-32,<br>
-1] does not span address 0 -- address 0 is the address one byte<br>
outside the range assigned to `array`.</font>
<br>
<br><font size=3>Digging more reveals that the formulation of inbounds
matches the C standard — not too surprisingly.</font>
<br>
<br><font size=3>C99 6.5.8/5 Relational operators</font>
<br>
<br><font size=3>If the expression P points to an element of an array object
and the expression Q points to the last element of the same array object,
the pointer expression Q+1 compares greater than P. In all other cases,
the behavior is undefined.</font>
<br>
<br><font size=3>So this works as expected without a potential overflow:</font>
<br>
<br><font size=3>for (char *p = array; p < array + sizeof(array); ++p)
…</font>
<br>
<br><font size=3>Adam</font>
<br>