Re: Faster code for IEEE arithmetic.

[Geoff Keating <geoffk at geoffk dot org>]

> From: Brad Lucier <lucier@math.purdue.edu>
> Date: Thu, 14 Dec 2000 00:57:41 -0500 (EST)
> Cc: lucier@math.purdue.edu (Brad Lucier), gcc-patches@gcc.gnu.org
> 
> Geoffrey Keating writes:
> > 
> > Brad Lucier <lucier@math.purdue.edu> writes:
> > 
> > > 2.  Can floating-point arithmetic trap?  If so, can we simplify code
> > > so that a trap is avoided in simplified code?  If not, can more
> > > optimizations be applied?
> > 
> > This is actually two items.  One is
> > 
> > 2a. Are there NaNs in floating-point arithmetic?
> > 
> > and another is
> > 
> > 2b. Might floating-point traps be enabled?
> 
> I fail to see where your 2a comes into consideration except in the two cases
> I listed as 2 and 3, namely, might some instructions trap (and if
> one is allowing signalling NaNs, then the answer might be yes) and
> are we allowing only those code transformations that preserve meaning
> (so fewer meaning-preserving transformations are allowed if the arithmetic has
> NaNs).  Non-IEEE floating-point systems can trap (or not), and IEEE 
> floating-point systems can be set up to trap (or not) on, e.g., 0./0..
> 
> I'm trying to characterise the various functional characteristics of code
> generation.  Whether there are NaNs or not, and whether they are
> signalling or not, seems to be included in my classification.  Outside
> of these areas, I see no separate issue with the existence of NaNs.

> What implications of the existence of NaNs didn't I cover in my note?

Here are some things which are related to 2a:

- Is '! (a >= b)' equivalent to 'a < b'?
- Does 'sqrt(-1)' have a defined result?
- Is 'a - a' equal to 0?

Often people know that their FP arithmetic only needs to work for
'regular' values: no denormals, no infinities, no NaNs.  It's a
separate question as to whether, for instance, you re-order

t = a - b;
t = t + c;

into

t = a + c;
t = t - b;

because this will change the behaviour of code even for regular
values.

By comparison, 2b is (for instance) always true in Java, even though
Java has NaNs, because FP exceptions are always disabled for Java
code.  GCC currently doesn't properly handle the possibility of
floating-point traps very well.

-- 
- Geoffrey Keating <geoffk@geoffk.org>