On 01/25/2017 11:09 PM, Marc Glisse 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;
}
So, it's not terrible to catch this in a manner similar to how we find
other ADD_OVERFLOW cases. And the positive is that we obviously pick it
up for cases created by my match.pd pattern or if the user wrote it
explicitly.
With my match.pd pattern + some more code in tree-ssa-mathopts.c we get:
addl $1, %edi
movl $42, %eax
cmovnc %edi, %eax
Which is precisely what we want. An enterprising individual could
probably extend it further and catch overflows from increments other
than +-1.
The widening_mul pass (where this happens) is quite late in the
optimizer pipeline, so we're not losing the original benefits we were
looking for.
? On the other hand, the optimization is already very fragile, if I
write b<=a (which is equivalent since 1 != 0), it doesn't apply.
Looks like it's just an oversight.
WRT back-propagating in DOM. It's possible, but we have to open code
the detection, which is what I didn't like about my original tweak to
VRP -- detecting in match.pd is *so* much simpler.
I'm going to push the improvement to tree-ssa-mathopts.c further to make
sure I didn't goof anything badly there. That seems the most promising
path to me.
jeff
