<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 2:14 PM, Nuno Lopes via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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"><span class=""><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"><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">
Or do you mean that the result of an add may not even be defined? In that case would reading it be considered UB in the case where the overflow bit was set?<br>
</blockquote>
<br>
Yeah, this is the case I'm worried about: that for example sadd.with.overflow(INT_MAX, 1) might be designed to return { poison, true } instead of giving a useful result in the first element of the struct.<br>
</blockquote>
<br></span>
Any argument against that?</blockquote><div><br></div><div>Yes, they were introduced to implement clang's __builtin_foo_overflow intrinsics which are explicitly documented to provide the two's complement behavior: <a href="http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins">http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins</a></div><div><br></div><div>"Otherwise, the builtin will return 1 and the result will be equal to the unique value that is equivalent to the mathematically-correct result modulo two raised to the k power, where k is the number of bits in the result type. The behavior of these builtins is well-defined for all argument values."</div><div> </div><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">  I guess that would be the most natural definition given the motivation to have these intrinsics (e.g., check if the 'nmemb * size' operation of calloc overflows; if so return null).<br>
<br>
InstCombine will remove these instrinsics if the overflow bit is unused, for example. AFAICT, InstCombine never adds nsw/nuw to the replacements.  I didn't check GVN.  But I think they should unless there's some reason not to.<br>
<br>
Nuno <br><div class=""><div class="h5">
_______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>