On Fri, 6 Mar 2009, Richard Guenther wrote: > There is of course the problem that we have to be careful not to > introduce new traps via folding, a problem that doesn't exist with > the no-overflow variants (I can simply drop to the wrapping variants). > With for example (a -/v 10) +/v 10 would you want to preserve > the possibly trapping a -/v 10? For (a -/v 10) +/v (b -/v 10) do > we want to be careful to not introduce extra traps when simplifying > to (a +/v b) -/v 20?
I think we should preserve the property of whether the code evaluated between sequence points causes no traps, or at least one trap. (But need not preserve the difference between one trap and two, for example. This is the same as C99 Annex F requirements for floating-point exceptions: the set of exceptions produced between calls to fenv.h functions checking or modifying exception state needs to be preserved, but not the number (> 0) of times each exception is produced.) This probably means that most folding should not apply to trapping variants. (In principle I believe folding should be done on GIMPLE rather than folding functions being called from the front ends on trees. If you do always lower to explicit overflow checks and only run folding after that lowering stage, the problem of changing whether a trap occurs does not arise. But with trapping variants in GIMPLE, the folding code would still need to allow for them even with folding all happening on GIMPLE.) > So while trapping variants can certainly be introduced it looks like > this task may be more difficult. So lowering them early during > gimplification looks like a more reasonable plan IMHO. If you lower to whatever forms of checks for overflow can be conveniently expressed in GIMPLE then you have the interesting problem of reconstituting trapping operations for those targets that have trapping instructions or instructions setting overflow flags that can be checked directly. It's possible that you want to lower to explicit overflow checks for targets without the operations, but to trapping operation codes for targets with the operations. (Which would suggest starting with trapping variants, and then lowering to explicit checks part way through the GIMPLE optimizations, only on targets without suitable instructions for the relevant type precision and depending on -Os to determine whether inline code or libgcc function calls might be better.) -- Joseph S. Myers jos...@codesourcery.com
