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

[Marc Glisse <marc dot glisse at inria dot fr>]

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