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


> Date: Tue, 4 Dec 2001 17:52:38 -0800
> Cc: Dale Johannesen <dalej@apple.com>, gcc-patches@gcc.gnu.org
> From: Dale Johannesen <dalej@apple.com>
> 
> 
> On Tuesday, December 4, 2001, at 03:22 PM, Geoff Keating wrote:
> 
> > Dale Johannesen <dalej@apple.com> writes:
> >
> >> This adds some additional patterns for multiply-add instructions.
> >> Bootstrapped and tested on Darwin.  (The !POWERPC variants are
> >> included, analogous to what was already there, but I was unable
> >> to test them.)
> >
> > I think that some of these are cases that should never occur.
> > Perhaps the generic code is not canonifing them properly?
> >
> > It might be that some of these are not strictly IEEE compliant, in
> > which case the generic code should still fold them... but only when
> > -ffast-math is specified.
> 
> It seems to be true that cases "fmsub 2" and "fnmsub 3" are not needed.
> All the rest can be generated by combine.  -ffast-math has an effect,
> in that it will change
>    neg (minus ((x)(y)))
> to
>    minus ((y)(x))
> only when -ffast-math is on.  This gets rid of 2 more patterns.

It seemed to me that at least when -ffast-math is on, none of the
extra patterns should be required, as combine should change the
expressions to only one of the possibilities.  It's much better to
change combine in this way than to add many extra patterns to
backends.

> 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 don't think this is a good idea.  I think we should have a mode in
which we support the C standard plus annex F; this means that while
expressions can be contracted, non-IEEE behaviour with respect to (for
instance) signed zero is not allowed, see section F.6.  This is a
useful mode, not least because the C standard permits implementations
to default to it while still providing IEEE conformance.  We should
also have a mode in which everything goes as fast as possible, which
is presently provided with -ffast-math.  One day we should even
implement the FP_CONTRACT pragma to give users full flexibility; at
present, we can emulate it with the -mno-fused-madd switch.

>  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?


-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


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