Re: Alpha -mieee Patch

[Tyson Whitehead <twhitehe at uwo dot ca>]

> (1) This has been the status quo on alpha since the beginning of time.
>     Not just with GCC, but with DEC C as well.  Why change now?

Default IEEE vs default non-IEEE compliance isn't a big deal if the OS 
supplies both IEEE conformant and non-IEEE conformant libraries and the 
dynamic loader links apps according to whether they were compiled with -mieee 
or not (i.e. DEC Unix and DEC C).

If the OS doesn't support IEEE compliant/non-IEEE compliant dynamic linking 
(i.e. Linux and probably every other OS besides DEC Unix), then the default 
should match the math libraries.

The GNU math libraries (I emailed them about this and they don't intend to 
change) generate IEEE 'extentions', so code compiled on systems build around 
the GNU libraries should be able to handle IEEE 'extentions' (i.e. on the 
Alpha, be compiled with -mieee).

For these systems it makes sense for -mieee to be a default, as nearly 
everything (except integer only program, which -mieee doesn't effect) has to 
be compiled with -mieee.  If they are not, then apps will, on specific user 
inputs, under non-esoteric conditions, crash (i.e. open up a version of 
Python/Perl compiled without -mieee and try doing exp(-710.0)*2.0 or write 
some C code and try erfc(27.0)*2.0, etc).

> (2) Particularly with pre-ev6 cpus, this results in severe penalties
>     of the performance for maths.

I did a little test the other day on an EV56 machine.  A hard coded C loop 
that took 1024 complex Fast Fourier Transform of 2048 vector doubles.  
Running time with -mieee was 11.4s.  Without was 9.4s.  Looks like -mieee 
makes a difference of 20% for an application that does nothing but crunch 
numbers in a tight loop.

20% is an upper bound.  Most intensive numerical simulations are more complex 
than FFTs or matrix inversions (i.e. have to maintain data structures for 
dynamic meshing, etc).  For a more average figure for a numerical number 
crunching app, I timed some of the code floating around our department.  
Monte Carlo option pricing; with -mieee 10.3s, without -mieee 10.2s.  
Molecular Dynamics simulation; with -mieee 191.0s, without -mieee 201.2s.

Realistically then, for an intensive numerical application (assuming it can 
even be compiled without -mieee -- the aforementioned Monte Carlo option 
pricing code can not, otherwise it occasionally crashes when it's random 
nature results in the generation of a denormalized number), we are only 
taking about a 5% difference.

> (3) Every time I looked at a non-math user application that got SIGFPE
>     due to subnormals, it was due to an uninitialized data read.

I decided to check our local Alpha RedHat Beowulf cluster to see how wide 
spread being able to not using -mieee actually is.  I did a disassemble of 
the installed libraries and grepped them for the ones that performed math 
operations (use FP registers other than in a store operation) without traps 
(i.e. without -mieee).  Only 98 of the 589 installed libraries that use the 
FPU are compiled without -mieee.  It seems that -mieee is required for the 
correct operation of most libraries/programs.

I traced the 98 libraries compiled without -mieee back to their packages.  Of 
the 50 resulting packages, only one was mathematics related (the GNU 
multiprecision arithmetic library).  LAPACK, BLAS, etc are all compiled with 
-mieee.  It looks like -mieee is required for the correct operation of the 
vast majority of computational libraries/programs (this is consistent with 
what you learn if you do a google search for -mieee and read all the confused 
emails from people new to the Alpha architecture).

Probably the situation would be different, if software routines did not 
generate denormalized numbers (then we would just have divide by zeros and 
such -- which are probably program bugs).  This is not the case for GNU based 
systems, however, so -mieee is required for the correct operation of the vast 
majority of libraries/programs.  It would seem reasonable then to make it a 
default.

(What is the advantage of not having it as a default?  Speeding up apps?  What 
apps?  Certainly not the numerically intensive ones like LAPACK, BLAS, etc -- 
they all appear to have to be compiled with -mieee.  Libtiff (one of the 50) 
then?  By what?  If it only makes a 5% difference to an intensive numerical 
simulation, what is it going to do to libtiff?  0.1%?  0.01%?)

> (A) At the extreme minimum, I require that -ffast-math result in
>     ieee math off, unless the user has explicitly enabled it for
>     some reason.

If someone knows how to do this (I would just put it in the spec file, but the 
spec file doesn't not appear to be architecture specific) I would appreciate 
hearing from you.  Possibly something with the OVERRIDE_OPTIONS macro?

> (B) I do not like a solution that changes the default for just one
>     operating system.  That's a bit of inconsistency that grates.
>     That means you'll need to track down the other users of alpha gcc
>     and get agreement.  I realize that this will be very difficult --
>     indeed, I *intend* for it to be difficult.

For sure, -mieee should be the default on all platforms that don't provide 
non-IEEE compliant math libraries and/or -mieee-conformant linking abilities 
(I would imagine that would be all GNU based systems).  I just made the patch 
for Linux as that was the OS I use/am familiar with and hoped users of other 
platforms would see it as a good idea and adopt it.

Later  -T

PS:  I guess you're the defacto Alpha GCC toolchain guy (from what I hear on 
the news groups) though, so she's your call. :)

If you change your mind and think it might not be such a bad idea, I'm willing 
to take a deeper look into that -ffast-math option, when I get some time, to 
see what I can do.

-- 
 Tyson Whitehead  (-twhitehe@uwo.ca -- WSC-)
 Computer Engineer                        Dept. of Applied Mathematics,
 Graduate Student- Applied Mathematics    University of Western Ontario,
 GnuPG Key ID# 0x8A2AB5D8                 London, Ontario, Canada