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

[Andrew Trick]

> On Mar 27, 2015, at 9:17 AM, Philip Reames <listmail at philipreames.com> wrote:
> 
> On 03/27/2015 12:00 AM, Andrew Trick wrote:
>>> On Mar 26, 2015, at 11:52 PM, Sanjoy Das <sanjoy at playingwithpointers.com <mailto: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.

Not a crazy idea at all, but it mostly defeats the purpose of the intrinsic and takes power away from the frontend. Frontends use the intrinsics when it’s important to effectively guarantee the best codegen knowing that the optimizer could otherwise obscure the overflow check. Getting that codegen right is often more important than whatever other optimizations may be inhibited by the intrinsic. If the frontend wants to give the optimizer free reign, then it simply shouldn’t use the instrinsics.

Andy

>> 
>> 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 <mailto:LLVMdev at cs.uiuc.edu>         http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/23bc0cb1/attachment.html>