This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Document arithmetic overflow semantics
Fergus Henderson wrote:
Optimizers are only paralyzed by such semantics (undefined behaviour on
overflow) if it occurs in their *target* language, and can't be avoided.
If it occurs in their *source* language, then it is a boon for the optimizer.
Of course, many optimizations are done as tree->tree or RTL->RTL passes;
In that case, the target is the same as the source, and so such semantics
can both help (in some cases) and hinder (in others), if the
thank you, I finally understand what this discussion is all about.
One way to get the best of both words is to provide bits on each
operation specifying the behaviour on overflow. The optimizer
can then convert operations with undefined behaviour into
operations with defined behavior if this helps it optimize.
Let me give an example.
Suppose we denote the three variants of "+" as follows:
+undef undefined behaviour on overflow
+wrap wraps on overflow
+trap traps on overflow
This makes sense. I think you need
op this_never_overflows
op dont_care
op modulo
op trap
op saturate (maybe).
optimizers are thus free to convert the first two into the final three. They
are also know that input values must be bounded such that the first one never
overflows.
This is why I think it would be much better to specify the overflow behaviour
by using flag bits on the operations, rather than on the types.
FWIW, I concur.
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
The voices in my head said this was stupid too
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org