On Fri, Jan 27, 2017 at 10:02 AM, Marc Glisse <marc.gli...@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