Re: [PATCH] Document arithmetic overflow semantics

[Nathan Sidwell <nathan@codesourcery.com>]

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