This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Document arithmetic overflow semantics


On 13-Feb-2003, Roger Sayle <roger@www.eyesopen.com> wrote:
> 
> Hi Richard,
> > I *really* don't like defining the tree operations as having this overflow
> > behavior.    I have three major problems with it:
> >
> > (1) It removes the potential of optimizations that assume such overflow
> >     cannot occur in languages where it is undefined (C, C++, and Ada).
> 
> The fact that the behaviour of overflow is undefined in C, C++ and Ada
> does not mean that "overflow cannot occur".  Quite clearly overflows do
> occur, and the optimizers are paralyzed by the semantics in this event.

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

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

`+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.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]