This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Activate -mrecip with -ffast-math?
- From: tbp <tbptbp at gmail dot com>
- To: "Richard Guenther" <richard dot guenther at gmail dot com>
- Cc: "Uros Bizjak" <ubizjak at gmail dot com>, GCC <gcc at gcc dot gnu dot org>, "Giovanni Bajo" <rasky at develer dot com>, "Bradley Lucier" <lucier at math dot purdue dot edu>, "Roger Sayle" <roger at eyesopen dot com>
- Date: Mon, 18 Jun 2007 12:16:12 +0200
- Subject: Re: Activate -mrecip with -ffast-math?
- References: <46757B74.6010300@gmail.com> <84fc9c000706180226p6253f55fy1ad037c876f6e1c8@mail.gmail.com>
On 6/18/07, Richard Guenther <richard.guenther@gmail.com> wrote:
Of course there are cases with every optimization enabled by -ffast-math that
can break existing programs. Just that we know of one case beforehand shouldn't
prevent us from enabling -mrecip at -ffast-math (provided -mno-recip
still works,
regardless if provided before or after -ffast-math). [We'll at least
get some more
testing coverage this way]
Argh! Please do not make -ffast-math even more of a pain to work with
than it is already.
You have to enable it, on the whole compilation unit, to get anywhere
near decent performance; there's no escape: either you do not turn it
on and everything slows to a crawl, or you pay for not being able to
inline from another unit.
Until now, the contract was: you have to deal with (and contain) NaN
and infinities. Fair enough, even if tricky that remained manageable.
But if i can't expect a mere division by 0, or sqrt of 0 (quite common
with FTZ/DAZ on) to give me respectively an infinite and 0 and instead
get a NaN (which i can't filter, you remember?) because of the NR
round, that's pure madness.
So please, for the love of everything's sacred, leave such stunts out
of -ffast-math.
PS: and it's not like such reciprocals + NR couldn't be done with
intrinsics or easily handle such common case.