public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).