On Fri, 29 Feb 2008, Robert Dewar wrote: > > If it were done at gimplification time I imagine something like the libgcc > > code would be used, but with conversions to/from unsigned inserted as > > needed. It would be possible to do optimizations at gimplification time if > > one argument is constant (converting to a range check). > > Well presumably one would want to use target dependent stuff for > detecting overflow where it exists (sticky overflow bits on > power, O flag on PC, trapping add on MIPS etc).
On the whole I think you'd want to benefit from tree-ssa optimizing overflow checks where possible (including optimizing them away with VRP), if you hope for a -ftrapv that could be turned on by default for Ada with performance impact as small as possible. That would suggest back ends matching overflow-check patterns (including any that might have been written manually in the user's code) and converting them into such instructions. (Or expand or a late tree-ssa pass doing so.) But you could choose to use built-in functions corresponding to the present libgcc functions to represent overflow-checking operations, rather than expanding inline, and you could make the choice of whether to do so target-dependent. (One possibility is also using such builtins at gimplification time and then optimizing them later in tree-ssa - for example, converting a built-in checked multiplication to a range check if other optimizers make one argument into a constant.) The only targets defining the <operation>v<mode> insn patterns at present appear to be alpha and pa. -- Joseph S. Myers [EMAIL PROTECTED]
