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

[Philip Reames]

On 03/27/2015 12:00 AM, Andrew Trick wrote:
>> 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.
Possibly crazy idea, but could we lower incoming x.with.overflow to 
their IR equivalents and then rematch later? This would seem to get us 
the best of both worlds provided that there aren't key cases where we 
can optimize the intrinsics better than the IR patterns.
>
> 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
>> }
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev