Re: Reorganize -ffast-math code.

[Andreas Jaeger <aj at suse dot de>]

Brad Lucier <lucier@zakon.math.purdue.edu> writes:

> Since Joseph Myers was kind enough to show an interest in my
> suggestion of
> 
> http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00690.html
> 
> I decided to reconstruct my changes for the current CVS head.
> 
> The purpose here is to separate and rationalize the various
> purposes for which flag_fast_math is used in various parts of gcc.
> The following patches removes flag_fast_math from toplev.c and
> introduces two new flags
> 
> int flag_unsafe_math_optimizations = 0;
> int flag_trapping_math = 1;
> 
> with associated options -funsafe-math-optimizations and
> -fno-trapping-math.
> 
> Together with the existing
> 
> int flag_errno_math = 1;
> 
> these three flags seem to encapsulate all the different uses
> that flag_fast_math fills at the moment.
> 
> The -ffast-math option still exists, it simply sets these
> three flags to the opposite of their defaults; -fno-fast-math
> resets them to their defaults.  These flags can be interspersed,
> they are interpreted in order and can override each other.
> 
> These patches also fix an association error in fold_const.c, as
> reported in optimization/2175.
> 
> I bootstrapped the compiler with --enable-languages=c,c++,f77,objc
> on i686-pc-linux-gnu with and without these patches.  These patches
> introduce no new warnings.  I couldn't get dejagnu installed
> properly on my intel box, and right now I can't get the trunk CVS
> to build on my alphaev6-unknown-linux-gnu box, so I have no
> test results yet.  (The patches did apply cleanly on my alpha box
> with a new CVS checkout after being generated on my intel box.)
> Perhaps someone else with a working dejagnu setup and an interest
> in these patches could test them.
> 
> Brad Lucier
> 
> Here are some comments and questions about the patches:
> 
> 	* gcc/config/convex/convex.md: Why is flag_fast_math checked before
> 	generating builtins?  Do these builtins incompletely implement
> 	these functions for all IEEE arguments and results?  If so, then
> 	we should go with my change to check flag_unsafe_math_optimizations
> 	instead of flag_fast_math.  If this is just to make sure that
> 	errno is set properly, this is checked in gcc/builtins.c
> 	(expand_builtin_mathfn) if flag_errno_math is 1 (the default),
> 	so the check is not needed here.
> 	* gcc/config/i386/i386.md: Same questions.
> 	* gcc/config/m68k/m68k.md: Same questions.
> 	* gcc/config/mips/mips.md: Same questions.
> 	* gcc/gcc.c: __FAST_MATH__ does not appear anywhere in the source
> 	tree, and I can't see the utility of this definition.

Check on a glibc 2.1+ system <bits/mathinline.h>.  We use some inlines
if we know that the user has added -ffast-math:

/* __FAST_MATH__ is defined by gcc -ffast-math.  */
#ifdef __FAST_MATH__

I would even suggest to added flags for the two other flags so that
they can be used by system software like glibc.

Thanks,
Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj