This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- To: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Subject: Re: What is acceptable for -ffast-math? (Was: associative law in combine)
- From: Gabriel Dos_Reis <gdosreis at sophia dot inria dot fr>
- Date: Wed, 1 Aug 2001 20:46:59 +0200 (MEST)
- Cc: Gabriel Dos_Reis <Gabriel dot Dos_Reis at sophia dot inria dot fr>, Wolfgang Bangerth <wolfgang dot bangerth at iwr dot uni-heidelberg dot de>, gcc at gcc dot gnu dot org, tim at hollebeek dot com
- References: <Gabriel.Dos_Reis@sophia.inria.fr><15208.17962.179912.327778@perceval.inria.fr><200108011827.f71IRBI09980@mururoa.inria.fr>
| Gabriel.Dos_Reis@sophia.inria.fr said:
| > | and probably a whole lot of other things that are equally "dubious".
| > | | | > But then, if they would have written that form in the first
| > place. | | But, as I said, there might be cases where you can't write
| > it in an | optimized way in the first place, such as in | inline
| > double f() { return a/b; } | inline double g() { return c; } | x
| > = f()/g(); | plus inlining.
|
| > But then is 0.0 is acceptable for 0.125 for speed?
|
| Yes, if you know by advance that this cannot happen because of your
| input data accuracy. Then you will get the speed advantage without
| the loss of accuracy since it cannot happen.
Data for the supposed speed in such case are still missing.
-- Gaby