[PATCH] Document arithmetic overflow semantics

[Joe Buck]

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.