Faster code for IEEE arithmetic.

[Geoff Keating]

> From: Brad Lucier <lucier@math.purdue.edu>
> Date: Thu, 14 Dec 2000 10:52:21 -0500 (EST)
> Cc: lucier@math.purdue.edu, gcc-patches@gcc.gnu.org
> 
> Geoffrey Keating writes:
> > 
> > > From: Brad Lucier <lucier@math.purdue.edu>
> > > 
> > > 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?
> > > 
> > 
> > > 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.
> 
> OK, I understand this, but I don't associate it with the existence
> of NaNs in particular, but with the existence of any "special"
> FP values.  For example the question
> 
>  - Is 'x + 0.' identical to x?
> 
> is true for all IEEE fp values except -0., so here it isn't
> NaNs that screw you up, but -0.  (I use "identical" here because
> +0. is "equal" to -0. in the sense of ==.)

Yes.  (I guess these people don't care about -0 vs. +0, either.)

> > By comparison, 2b is (for instance) always true in Java, even though
> > Java has NaNs, because FP exceptions are always disabled for Java
> > code.
> 
> So a -fno-trapping-fp flag, automatically enabled for Java and taken
> into account in can_trap_p for fp expressions, would immediately enable
> better optimization for Java by allowing more code movement.

Yes.

In fact, there are actually two levels of 2b, which I should really
have distinguished.  One level is that the program doesn't care about
traps at all.  The next level is that the program will, at certain
points, check the FPU status to see what traps have happened, but
doesn't expect to get a signal when a trap happens.

The middle level actually allows very significant optimisations---or
perhaps I should say that not having it prohibits many optimisations.
You can't, for instance, combine

t1 = b + c;
t2 = b + c;

into

t1 = b + c;
t2 = t1;

because if 'b + c' would trap, and a handler is counting the number of
traps, then this changes program behaviour.  You can't re-order
operations, because

t1 = b + c;
t2 = d + e;

might give two different exceptions (say an overflow than an invalid)
and a handler might expect that ordering.

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