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

[zackw at panix dot com]

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.)

> I sort of think GCC should have built-in functions exposing C and C++ 
> interfaces for: each basic arithmetic operation, defined to wrap; each 
> basic arithmetic operation, defined to saturate; each basic arithmetic 
> operation, defined to have undefined overflow; each basic arithmetic 
> operation, with a separate overflow flag being set; each basic arithmetic 
> operation, defined to trap on overflow.  All of these for both signed and 
> unsigned and for any desired number of bits (up to the maximum number 
> supported for arithmetic, so generally 1-64 bits on 32-bit configurations 
> and 1-128 bits on 64-bit configurations); except for the defined-to-trap 
> case, all would still have undefined behavior on division by 0.  You could 
> then have optimizations mapping generic C idioms to such built-in 
> operations where the target supports efficient code for the operations.  
> But this rather relies on the no-undefined-overflow work being finished 
> first so that some of the required operations actually exist inside GCC, 
> before they can easily be exposed to the user.

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.