Re: Faster code for IEEE arithmetic.

[Brad Lucier <lucier at math dot purdue dot 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?

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.

But perhaps I'm wrong, so can I phrase the question in this way:
What implications of the existence of NaNs didn't I cover in my note?

Brad