[llvm-dev] x.with.overflow semantics question

David Majnemer via llvm-dev llvm-dev at lists.llvm.org
Sun May 8 15:19:26 PDT 2016

On Sun, May 8, 2016 at 2:14 PM, Nuno Lopes via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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?
>> 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.
> Any argument against that?

Yes, they were introduced to implement clang's __builtin_foo_overflow
intrinsics which are explicitly documented to provide the two's complement

"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

>   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).
> 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.
> Nuno
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160508/21f1ed5a/attachment.html>

More information about the llvm-dev mailing list