<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 10:54 PM, Adam Nemet <span dir="ltr"><<a href="mailto:anemet@apple.com" target="_blank">anemet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Bjarke,<div><br><div><span class=""><blockquote type="cite"><div>On Jun 30, 2015, at 6:16 PM, Bjarke Roune <<a href="mailto:broune@google.com" target="_blank">broune@google.com</a>> wrote:</div><br><div><div dir="ltr"><div>Hi Adam,</div><div><br></div>Jingyue is right. We need to keep things in 32 bits because 64 bit arithmetic is more expensive and because one 64 bit register consumes two 32 bit registers.<div><div><br></div><div>To add a bit more background: we would often emit worse code if we widened in indvars and then narrowed in the NVPTX backend later because we often would not be able to narrow AFAICT. Consider this general pattern where everything is 32 bit:<div><br></div><div>  for (int i = a; i < b; i += s) {</div><div>    // ...<br>  }</div><div><br></div><div>Suppose we widen i to be 64 bit:</div><div><br></div><div><div>  for (int64 i = a; i < b; i += s) {</div><div>    // ...<br>  }</div></div><div><br></div><div>As an example, suppose a = 0, b = INT_MAX, s = 2. The final value of i that makes the loop terminate would then be INT_MAX+1, so we cannot narrow i to 32 bits.</div></div></div></div></div></blockquote><div><br></div></span><div>Is the original program defined for s = 2 and b = INT_MAX?  Seems to me that last increment (INT_MAX - 1 + 2) before the exit condition should generate a poison?  (From the original post, it seemed you were assuming C/C++ overflow rules.)</div><span class=""><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div>That's true, though that doesn't let us narrow because the narrowing pass does not have information about the original program (though with an assume intrinsic perhaps it could, but that again would require proving that poison would lead to UB, since violating an assume is UB).</div><div><br></div><div>I'm assuming that we're translating from C into LLVM IR with the nsw flag and then using LLVM's less strict rules for overflow. In the original loop, it could be the case that s=2, b=INT_MAX, a=0, but then we could assume that the effect of the poison/overflow that this creates is not externally observable due to the 32 bit nsw on i += s. That makes it sound to widen.</div><div><br></div><div>Once we have widened, we lose some information. In particular, the nsw flag on i += s is now a 64 bit nsw. So when we want to narrow back to 32 bit, there is nothing that guarantees that the overflow that would be produced by s=2, b=INT_MAX, a=0 could not be observed so narrowing is then unsound from the perspective of the narrowing pass.</div><div><br></div><div>Bjarke<br></div></div></div></div>