On Fri, 6 Mar 2009, Geert Bosch wrote: > > On Mar 6, 2009, at 12:22, Joseph S. Myers wrote: > > If you add new trapping codes to GENERIC I'd recommend *not* making fold() > > handle them. I don't think much folding is safe for the trapping codes > > when you want to avoid either removing or introducing traps. Either lower > > the codes in gimplification, or handle them explicitly in a few GIMPLE > > optimizations e.g. when constants are propagated in, but avoid general > > folding for them. > > The point here is not to think in terms of the old -trapv and trapping > instructions, but instead at the slightly higher level of a well-defined > model of signed integer arithmetic. That is why signed integer overflow > checking and the no-undefined-overflow branch are closely related. > > There are essentially two models to evaluate a signed integer expression. > The one Ada uses is that a check may be omitted if the value of the > expression, > in absence of the check, would have no effect on the external interactions > of the program. > > > An implementation need not always raise an exception when a language-defined > > check > > fails. Instead, the operation that failed the check can simply yield an > > undefined > > result. The exception need be raised by the implementation only if, in the > > absence > > of raising it, the value of this undefined result would have some effect on > > the > > external interactions of the program. In determining this, the > > implementation shall > > not presume that an undefined result has a value that belongs to its > > subtype, > > nor even to the base range of its type, if scalar. Having removed the raise > > of > > the exception, the canonical semantics will in general allow the > > implementation > > to omit the code for the check, and some or all of the operation itself. > > The other one is the one you suggest: > > Front ends should set TREE_SIDE_EFFECTS on trapping expressions so that > > fold knows it can't discard a subexpression (whose value doesn't matter to > > the value of the final expression) containing a trapping expression, e.g. > > 0 * (a +trap b) needs to evaluate (a +trap b) for its side effects. With > > this done, front ends generating trapping codes for -ftrapv and fold not > > trying to optimize the trapping codes, I'd hope fold and the rest of the > > language-independent compiler could stop caring about flag_trapv. > > Setting the TREE_SIDE_EFFECTS seriously limits optimizations. Also, as quality > of implementation issue, while an expression may have an undefined result, > if that result is not used, removing the entire computation is generally > preferable over raising an exception. Arguments can be made for and against > both > models, so probably we could make setting of TREE_SIDE_EFFECTS optional.
Yes. If we introduce new GENERIC tree codes for overflow checking operations that is certainly useful. Though once you lowered GENERIC to explicit checks and trapping (or raising exceptions) then this side-effect is explicit and we probably won't remove them anymore. I played with the idea to just implement a -ftrapv substitute by lowering non-NV operation variants during gimplification, but of course new GENERIC tree codes are more flexible. You can use no-undefined-overflow branch to commit patches once you have them. Thanks, Richard.
