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.
-Geert
