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

[David Majnemer via llvm-dev]

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
behavior:
http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins

"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."


>   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>