http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011.04.13 12:11:47
CC| |rguenth at gcc dot gnu.org
Component|rtl-optimization |middle-end
Ever Confirmed|0 |1
--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-04-13
12:11:47 UTC ---
I too would see it as two pieces, pattern matching on trees to produce
a canonical builtin call and RTL expansion of that for optimal target
code generation (where I don't know whether we can do better than using
UNSPECs). Note that usually you also want to use the result of the
multiplication (if it didn't overflow), and using just a single
multiplication might be even more complicated (if we need to go the
UNSPEC way).
For the latter reasons I think the builtins should be sth like
__builtin_smul_ovfl_p (multiplication-result, op0, op1), thus pass
in the multiplication result and keep the multiplication itself
in the IL to also allow for regular optimizations to work on them.
If the multiplication is just used as the builtin call argument
expansion can get rid of it.
The set of builtins with defined behavior is still useful, if not
only to allow mixing of wrapv/trapv/... operations in C source.
But it isn't exactly the form I'd like the operations to reside
in the IL.
Pattern-matching the multiplication overflow code can be tricky
because of the various ways the handling of zero operands can
be implemented. Implementing this entirely on the RTL side seems
very tricky to me.
