llvm dev - Mar 2015 - [LLVMdev] `llvm.$op.with.overflow`, InstCombine and ScalarEvolution

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

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

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