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

[Sanjoy Das via llvm-dev]

CGP also relies on the add being a simple two's complement add, since it will transform

define void @test1(i64 %a, i64 %b, i64* %res_i64, i1* %res_i1) {
entry:
   %add = add i64 %b, %a
   %cmp = icmp ult i64 %add, %a
   store i1 %cmp, i1* %res_i1
   store i64 %add, i64* %res_i64
   ret void
}

to

define void @test1(i64 %a, i64 %b, i64* %res_i64, i1* %res_i1) {
entry:
   %uadd.overflow = call { i64, i1 } @llvm.uadd.with.overflow.i64(i64 %b, i64 %a)
   %uadd = extractvalue { i64, i1 } %uadd.overflow, 0
   %overflow = extractvalue { i64, i1 } %uadd.overflow, 1
   store i1 %overflow, i1* %res_i1
   store i64 %uadd, i64* %res_i64
   ret void
}


Now if we _know_ that the arithmetic result is used only if it does not overflow, then we can "pretend" that the 
arithmetic was nsw/nuw.  This is what I tried to do in http://reviews.llvm.org/rL265912, but I had to back out the 
change due to an unrelated issue with SCEV.

-- Sanjoy

Nuno Lopes via llvm-dev 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? 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