From: Andrew Pinski <pinskia@physics.uc.edu>
To: neroden@twcny.rr.com (Nathanael Nerode)
Cc: gcc@gcc.gnu.org, Andrew Pinski <pinskia@physics.uc.edu>
Subject: Re: Making -ffast-math more fine-grained?
Date: Wed, 24 Mar 2004 15:44:00 -0000 [thread overview]
Message-ID: <69F59AB2-7D55-11D8-AA55-000393A6D2F2@physics.uc.edu> (raw)
In-Reply-To: <20040324052059.GA12623@twcny.rr.com>
I thought we have already have some of these flags already, yes we do:
On Mar 23, 2004, at 21:20, Nathanael Nerode wrote:
> 1 * Ones which allow excess precision computations (these really
> should be OK
> for most people, though not for testsuites)
Done by default on targets which support 80bit math as faster than
64bit would.
I do not think this is going to change any time soon.
> 2 * Ones which ignore correct behavior for anything with NaN or
> infinities
> (and maybe -0.0 vs. +0.0) as intermediate computations, but behave
> properly with real numbers (there's probably a class of users who would
> appreciate this)
-ffinite-math-only Assume no NaNs or infinities are generated
> 3 * Ones which slightly reduce accuracy by doing truncations instead of
> rounding, etc., but where meaningful bounds on the accuracy can be
> computed
> (I'm sure there's a class of users who would appreciate this)
-frounding-math Disable optimizations that assume default
FP
rounding behavior
> 4 * Ones which only work when the exponents involved are close (and
> are only
> useful in cases which should have been coded in fixed-point arithmetic)
> such as (a+b)+c => a+(b+c) mentioned by Robert Dewar recently, which
> are really
> dangerous
-funsafe-math-optimizations Allow math optimizations that may violate
IEEE or
There are some which you missed and are unset by -ffast-math (they are
set by defualt):
-fmath-errno Set errno after built-in math functions
-fsignaling-nans Disable optimizations observable by IEEE
signaling NaNs
-ftrapping-math Assume floating-point operations can trap
/* The following routines are useful in setting all the flags that
-ffast-math and -fno-fast-math imply. */
void
set_fast_math_flags (int set)
{
flag_trapping_math = !set;
flag_unsafe_math_optimizations = set;
flag_finite_math_only = set;
flag_errno_math = !set;
if (set)
{
flag_signaling_nans = 0;
flag_rounding_math = 0;
}
}
Thanks,
Andrew Pinski
next prev parent reply other threads:[~2004-03-24 5:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-24 14:42 Nathanael Nerode
2004-03-24 15:44 ` Andrew Pinski [this message]
2004-03-24 18:29 ` Roger Sayle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69F59AB2-7D55-11D8-AA55-000393A6D2F2@physics.uc.edu \
--to=pinskia@physics.uc.edu \
--cc=gcc@gcc.gnu.org \
--cc=neroden@twcny.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).