[LLVMdev] `llvm.$op.with.overflow`, InstCombine and ScalarEvolution

[Andrew Trick]

> On Mar 26, 2015, at 11:52 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
>> If we don't care about trying to optimize out overflow checks in
>> InstCombine, I'd go with moving the complexity to CGP.
> 
> I think instcombine should optimize out overflow checks (as it does
> today) without introducing _with_overflow calls.  Are there reasons
> why such an approach would not work?

I agree. I think that approach would work in any case simple enough for InstCombine to otherwise convert the same compare/branch into a with_overflow intrinsic.

I think the problem we run into is that we also want to optimize the _with_overflow cases that are generated by some frontends. We are stuck with some duplication of effort.

Either way, I think the optimizer should handle compare-and-branch idioms first and foremost.

Andy

>> However, I think
>> InstCombine is doing the right thing here by forming these.
> 
> I don't quite agree with you on this -- by materializing these
> intrinsics InstCombine is making every pass that runs after it less
> effective.  All of them have to know about the _with_overflow
> intrinsics to optimize IR that it could have otherwise optimized.
> 
> Another example is GVN -- `opt -gvn` optimizes away %to.optimize but
> `opt -instcombine -gvn` does not.
> 
> declare void @side_effect(i1)
> 
> define void @foo(i8 %x, i8 %y) {
> entry:
>  %sum = add i8 %x, %y
>  %e = icmp ugt i8 %x, %sum
>  br i1 %e, label %yes, label %no
> 
> yes:
>  %to.optimize = icmp ugt i8 %x, %sum
>  call void @side_effect(i1 %to.optimize)
>  br label %no
> 
> no:
>  ret void
> }