Re: What is acceptable for -ffast-math? (Was: associative law in combine)

["Tim Prince" <tprince@computer.org>]

----- Original Message -----
From: "Jan Hubicka" <jh@suse.cz>
To: "Tim Prince" <tprince@computer.org>
Cc: "Jan Hubicka" <jh@suse.cz>; "Toon Moene"
<toon@moene.indiv.nluug.nl>; "Joern Rennecke" <amylaar@redhat.com>;
<gcc@gcc.gnu.org>
Sent: Sunday, July 29, 2001 10:24 AM
Subject: Re: What is acceptable for -ffast-math? (Was: associative law
in combine)


> The mathinline is mostly mess.  I was thinking about rewriting it
myself.
> It seems to make sense to make target specific builtins for the i387
> features the header needs and use them, instead of using mostly
unusable
> i387 inline assembly.
glibc as a whole is so dependent on i386 assembly that it would be a
major project to change.  It might be interesting to include direct
support for more math intrinsics in gcc, but that begins to encroach on
the traditional separation between gcc and support libraries.  I suppose
this would involve built-ins for frexp(), ldexp() et al. in each
supported precision.  I fear that a noticeable amount of efficiency
could be lost, and we would remain with the question of full accuracy
and safety vs speed in certain cases.  A beginning would be to organize
mathinline.h so as to be based on such a group of builtins in order to
test them in the current framework.  This project may not offer
sufficient return without assurance of glibc taking advantage of it and
becoming more portable.
>
> If you have sanified version and you can get the copyring issues,
> please try to contribute the changed to glibc.
I took this far enough with the glibc maintainers to see that their
point of view does not allow introduction of any "safety features."  Now
I will be even further away, wanting to improve support for P4.
> >
> > In a large application, if something breaks when turning on a family
of
> > unsafe
> > optimizations, when there is no documented way of turning them on
> > individually,
>
> You can turn them individually and if they are not documented, I will
do
> so shortly.

Thanks
>
> Honza