[Bug rtl-optimization/48580] missed optimization: integer overflow checks

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-04-12 20:52:48 UTC ---
On Tue, 12 Apr 2011, zackw at panix dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
> 
> --- Comment #2 from Zack Weinberg <zackw at panix dot com> 2011-04-12 20:40:41 UTC ---
> (In reply to comment #1)
> > 
> > Two signed integers given that they are known to be positive, anyway.  
> > This may return unexpected results if either or both arguments are 
> > negative or zero.
> ...
> > (If the function gets called with one constant operand, you can make it 
> > inline and use __builtin_constant_p to replace a divide with a range check 
> > on the other operand.  That's only useful for some cases of overflow 
> > checks, of course.)
> 
> In the code that this is cut down from, both arguments are known to be strictly
> positive, but neither is constant.  (They're only signed for historical
> reasons, I think, but it would be a huge amount of work to change that.)

My point in noting the need for the integers to be positive was really 
that unless the compiler knows they are positive, the transformation 
you're asking for appears to be incorrect - the semantics of your function 
are that a product with either term 0 counts as overflowing, but using a 
processor overflow flag would report it as not overflowing.

> So you see this as more of a tree-level than an RTL-level missed optimization,
> then?  Your plan sounds fine to me, although I might look for a less ambitious
> but more likely to get done soon approach, personally.

I think it's both levels, but probably tree-level for spotting the 
patterns unless it seems likely that expansion or RTL optimizations will 
produce more instances of them.  And tree-level is where we have VRP 
information, if you want the compiler to tell that the arguments must be 
strictly positive that way.