<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>If it can help, another view of it: this can be seen as a promise from the user (or the frontend language) that this code/instruction will never ever be executed at runtime with values that would trigger an overflow*. So this is a contract the IR offers to the user/frontend (and the optimizations David mentions take advantage of this promise to generate better/faster code).</div><div><br></div><div>*Actually this is not correct, and I intentionally simplified because the detailed explanation is likely why it isn't easy to understand in LangRef. A slightly more elaborate explanation is that the instruction is allowed to overflow as long a nothing in the program depends on the the result of this instruction. </div><div>This is a way in LLVM to "delay" the effect of the overflow: there is no harm to overflow is the result of the instructions does not impact the program behavior anyway!</div><div>This is what the section on poison value tries to illustrate in LangRef: <a href="https://llvm.org/docs/LangRef.html#poisonvalues">https://llvm.org/docs/LangRef.html#poisonvalues</a></div><div><br></div><div>If you want to understand more undefined behavior in LLVM, this is good read: <a href="https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf">https://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf</a> (and blog post about this paper: <a href="https://blog.regehr.org/archives/1496">https://blog.regehr.org/archives/1496</a> )</div><div>Also, a talk at the LLVM dev meeting: <a href="https://www.youtube.com/watch?v=_-3Iiads1EM">https://www.youtube.com/watch?v=_-3Iiads1EM</a></div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 1, 2019 at 7:23 AM David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Practically, this means (roughly) two things:<br>
<br>
1. Optimisers can assume that overflow will not occur.  For example, <br>
that %22 >= %19 and %22 >= %21.  This can be used, for example, to <br>
reason about loop termination.<br>
<br>
2. If, after later optimisations, we learn enough about the values of <br>
%19 and %21 to determine that the operation will overflow, then we can <br>
replace it with undef.<br>
<br>
The latter is less useful, because this typically means the code is <br>
wrong (though it might also be dead, for example in C++ template <br>
instantiation where the programmer is relying on DCE removing <br>
unreachable code that would exhibit undefined behaviour).  The former is <br>
a lot more useful for exposing later optimisation opportunities.<br>
<br>
David<br>
<br>
<br>
On 01/03/2019 14:49, Cranmer, Joshua via llvm-dev wrote:<br>
> In simple terms, nsw (for no signed wrap) means you invoke C-style undefined behavior should the operation have an overflow when interpreted as a signed operation.<br>
> <br>
> -----Original Message-----<br>
> From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Peng Yu via llvm-dev<br>
> Sent: Friday, March 1, 2019 7:35<br>
> To: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> Subject: [llvm-dev] Meaning of `sub nsw`<br>
> <br>
> In the following code.<br>
>       unsigned char x1 = atoi(argv[1]);<br>
>       unsigned char x2 = atoi(argv[2]);<br>
>       printf("%d\n", x1-x2);<br>
> <br>
> The substraction of the last command is translated to the following IR code.<br>
> <br>
> %18 = load i8, i8* %6, align 1<br>
> %19 = zext i8 %18 to i32<br>
> %20 = load i8, i8* %7, align 1<br>
> %21 = zext i8 %20 to i32<br>
> %22 = sub nsw i32 %19, %21<br>
> <br>
> I don't follow the explanation of nsw in langref. Could anybody help explain what nsw means here? Thanks.<br>
> <br>
> <br>
> --<br>
> Regards,<br>
> Peng<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>