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
