This is the mail archive of the
mailing list for the GCC project.
Re: Efficient overflow checking (was: plans for nested functions)
- From: Gabriel Paubert <paubert at iram dot es>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: gcc at gcc dot gnu dot org, rth at redhat dot com
- Date: Mon, 29 Sep 2003 13:17:20 +0200
- Subject: Re: Efficient overflow checking (was: plans for nested functions)
- References: <20030927221437.EFB80F2E18@nile.gnat.com>
On Sat, Sep 27, 2003 at 06:14:37PM -0400, Robert Dewar wrote:
> In fact we identify the relatively inefficient implementation
> of nested functions as problematical in the Ada case., but there are
> far more worthwhile targets of opportunity (e.g. efficient
> arithmetic overflow checking).
Wouldn't this need a whole slew of new patterns for all architectures?
Or can it be introduced on a per architecture basis, or even on a
per pattern basis?
Besides that the optimal implementation may be very different depending
on architecture: trapping instructions on some (Alpha/S390), jump on
condition (most targets I believe, including x68-64 since AMD has removed
'into' from the list of valid opcodes in 64 bit mode), perhaps explicit
traps on overflow (m68k, also conditional jumps might also work).
For the target I know best (PPC), it would require using the overflow
recording version of the instructions, but only transferring the sticky
overflow bit to the condition register and testing for it before
doing unrecoverable damage, or when the language rules require it,
which is unlikely to be more than once per expression. Besides that,
the sticky overflow bit is transferred to the CR as a side effect of
compare instructions, which may open other optimization opportunities.
And I've not even discussed the overflow before storing into a narrower
mode, which is sometimes harder to check than the overflow on arithmetic
operations; an almost generic way is to shift left than right by the
right number of bits and then compare for equality, but that's a 4
instructions overhead per assignmnent. You may get smaller but
slower code by multiplying with a suitable constant if you have hardware
multiplies with overflow checking.
In short, I'd be very interested in getting fast overflow checking code
but it looks very complex. Perhaps I'm trying to get optimal code
too early, but if we don't keep the ultimate goal in mind, we might
go down the wrong path.