This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch: rs6000 specific


>>>>> Dale Johannesen writes:

> Let's see if we can agree on the goal here.  Multiply-add generation
> is controlled by the -fno-fused-madd switch, as you said.  IMO when
> multiply-add generation is on (as it is by default) we should recognize
> as many mathematically correct cases of it as possible, without concern
> for IEEE compliance, since it's not compliant anyway.  I do not mean
> combine should behave this way, only the ppc-specific code.  This implies
> that we can't rely on combine to make IEEE-unsafe transformations;
> this needs to be done in the ppc-specific patterns.  Do you agree with
> this, and if not, what do you think the goal should be?

	While IEEE compliance is a black-and-white issue, the effect of
the lack of compliance is not black-and-white.  There is a difference
between excess precision and unsafe transformations.

	The FMA family of instructions perform the same arithmetic
operations in the same order as operations performed independently, but
the intermediate results retain extended precision.  This does not
re-group operations, invert operations, reverse operations, etc.  Those
additional types of transformations may not produce the same result.

	GCC -ffast-math will produce the transformations you want.  If you
want those transformations, use -ffast-math.  If any transformations are
missing from -ffasth-math, then add them.

	I do not accept your premise that once GCC defaults to one thing
which violates IEEE compliance that anything is fair game.  The potential
effects of the lack of compliance are gradual.

David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]