Re: What is acceptable for -ffast-math? (Was: associative law in combine)

[Jan Hubicka <jh at suse dot cz>]

> Thanks for bringing this up.  This is an example of inflicting too many
> dangerous shortcuts
> under one option; worse, an option which kicks in by default already
> at -O, in violation
> of the rule you quoted above.  I myself use a saner version of
> <mathinline.h>.  It allows

The mathinline is mostly mess.  I was thinking about rewriting it myself.
It seems to make sense to make target specific builtins for the i387
features the header needs and use them, instead of using mostly unusable
i387 inline assembly.

If you have sanified version and you can get the copyring issues,
please try to contribute the changed to glibc.

> I don't see the decisions about options made by gcc having much
> influence on glibc, nor
> should the decisions made for glibc influence gcc when they don't make
> sense.  I see a
> need now for some changes in math library support for P4, but the level
> of interest may
> be insufficient.

The description quoted above states, that FLAG_FAST_MATH is defined and
so glibc is correct IMO to change the behaviour.

> >
> > I agree with idea of adding new options to control this feature, but
> as
> > options of -ffast-math, as
> the -funsafe-math-optimizations, -ftrapping-math
> > and -ferrno-math is currently implemented.
> This seems OK if we have a documented way to turn off individually the
> sub-options
> of -ffast-math.  I have been experimenting this morning with -ffast-math
> and trying to
> over-ride the individual options.  I think it works,
> but -march=pentiumpro -ffast-math
> has lost its good effect for P-III in g77-3.1 now that short IF blocks
> are producing
> jumps out of line.  gcc has not picked up this behavior, but I see now
> that -ffast-math
> is no longer required to obtain efficient code for floating point
> compare and branch.

OK, I will document the new options in -ffast-math, as we document these
on -Ox and send a patch shortly.
> The pre-inversion may make noticeable differences in accuracy, and those
> may well
> be of concern.  It shouldn't fail on an IEEE-compliant architecture, in
> the normal
> course of events.  As others pointed out, the re-association of division
> makes
> opportunities for changes in over- and under-flow behavior, from which
> IA32
> architectures will no longer be protected, with the increasing use of
> SSE
> instructions.

We may jump into something like -fapproximate-fp-math allowing transformation
with loss of effciency if that makes sense.
> 
> In a large application, if something breaks when turning on a family of
> unsafe
> optimizations, when there is no documented way of turning them on
> individually,

You can turn them individually and if they are not documented, I will do
so shortly.

Honza