This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFA][PR tree-optimization/79095] Improve overflow test optimization and avoid invalid warnings
On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> 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...
Yeah, and it's still on my TODO to add some helpers exercising
match.pd COND_EXPR
patterns from PHI nodes and their controlling condition.
>>> 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