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.
