[PATCH][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings

Marc Glisse marc.glisse@inria.fr
Fri Jan 27 09:13:00 GMT 2017


On Thu, 26 Jan 2017, Jeff Law wrote:

>> I assume this causes a regression for code like
>> 
>> unsigned f(unsigned a){
>>   unsigned b=a+1;
>>   if(b<a)return 42;
>>   return b;
>> }
> Yes.  The transformation ruins the conversion into ADD_OVERFLOW for the +- 1 
> case.  However, ISTM that we could potentially recover the ADD_OVERFLOW in 
> phi-opt.  It's a very simple pattern that would be presented to phi-opt, so 
> it might not be terrible to recover -- which has the advantage that if a user 
> wrote an optimized overflow test we'd be able to recover ADD_OVERFLOW for it.

phi-opt is a bit surprising at first glance because there can be overflow 
checking without condition/PHI, but if it is convenient to catch many 
cases...

>> We currently get
>>     addl    $1, %edi
>>     movl    $42, %eax
>>     cmovnc    %edi, %eax
>> or almost as good with b==0
>>     movl    %edi, %eax
>>     movl    $42, %edx
>>     addl    $1, %eax
>>     cmove    %edx, %eax
>> while with a==-1 we have the redundant comparison
>>     leal    1(%rdi), %eax
>>     cmpl    $-1, %edi
>>     movl    $42, %edx
>>     cmove    %edx, %eax
>> 
>> Simplifying x + 1 < x to x + 1 == 0 might not be enough to simplify your
>> examples though I guess?
> It's an interesting idea.  But x+1 == 0 will get canonicalized back into x == 
> -1.

Well, it doesn't always get canonicalized since I got different code above 
for b==0 and for a==-1. There may be another single_use check in there. 
But that was probably not a good idea anyway.

-- 
Marc Glisse



More information about the Gcc-patches mailing list