Re: Faster code for IEEE arithmetic.

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Thu, 14 Dec 2000 13:26:22 -0500 (EST)
> From: Brad Lucier <lucier@math.purdue.edu>
> Cc: gcc-patches@gcc.gnu.org

> > From geoffk@geoffk.org  Thu Dec 14 13:00:20 2000
> > > From: Brad Lucier <lucier@math.purdue.edu>
> > > Geoffrey Keating writes:
> > > > 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.
> 
> Perhaps I'm not seeing the distinction here.  From my point of view,
> IEEE fp is implemented by a combination of compilers, libraries, and
> the kernel; where sqrt(-1.) is turned into a NaN doesn't matter to the
> person running the program, only whether the program traps at that
> point or not. 

I am also not distinguishing between the compiler, libraries, and the
kernel.

> This is quite clear on alphaev5 under linux; the
> compiler generates trapb instructions in some places, which does not
> mean a user visible trap, just that the kernal must clean up here if
> there is an exceptional condition.  And some aspects of IEEE fp
> (correct functioning of sqrt, for example) are implemented in the
> libraries.
> 
> It is true that if an "exceptional event" occurs, whether trapping or
> not, certain flags, which can be examined later by some mechanism in
> principle, must be set.

There are two ways to monitor such exceptional events.

One way is to have them cause a signal, typically SIGFPU, which then
calls a user-level signal handler.  To get this right, the compiler
must ensure that the user-level handler is called the right number of
times in the right order as implied by the code.

Another way is for the program to look at summary flags, using the
interface in the <fenv.h> header.  This way allows the system much
more freedom in re-ordering and combining operations, but it still
can't (for instance) eliminate an operation altogether if it can't be
sure it doesn't cause an exceptional event.

The program, in C99, can also declare that it doesn't even care about
the summary flags for a region of code (or to be more precise, it has
to declare for which regions of code it _does_ care), using a pragma.

> I don't believe that there is a concept of "counting exceptional
> events" in IEEE fp; on an exceptional event, certain flags are set,
> period, and one can later determine *what* flags were set, but not *how
> many times* they were set, or *in what order* they were set.

Sure there is.  IEEE754 refers, I believe, to 'trap handlers'.

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