Re: [PATCH] Document arithmetic overflow semantics

[Richard Earnshaw <rearnsha at arm dot com>]

> On Fri, Feb 14, 2003 at 05:27:46AM +1100, Fergus Henderson wrote:
> > 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.
> 
> Exactly: we need to be able to distinguish between operations provided
> by the user (which have undefined overflow behavior), and operations
> available for mapping to (which have defined overflow behavior that
> we can exploit).
> 
> > 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
> > 
> > `+wrap' is associative, so an optimizer can replace `x +wrap (y +wrap z)'.
> > with `(x +wrap y) +wrap z'.  But `+undef' is not, so an optimizer cannot
> > replace `x +undef (y +undef z)' with `(x +undef y) +undef z'.  
> > However, if the target language supports both kinds, the optimizer can
> > convert from +undef to +wrap when desired, so it can safely replace
> > `(x +undef y) +undef z' with `x +wrap (y +wrap z)'.
> > 
> > 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.
> 
> I find this argument convincing.

Rather than having lots of differnent plus nodes, why not have plus mean 
the mathematical operation (done in "infinite" precision and then define a 
series of "reduction" nodes that can be applied to it.

Examples would be

	wrap		Reduce to 2's complement
	trap		trap on overflow
	sat		Saturate
	
That way a C expression such as

x = a + b + c;

can be compiled as

	x = truncop (plus (plus (a, b), c))

And a language which applied specific semantics to the above could expand 
this to

	x = truncop (plus (truncop (plus (a, b)), c))

R.