[llvm-commits] [PATCH] Aggressive FMA formation mode.

Lang Hames lhames at gmail.com
Tue Jun 19 08:47:53 PDT 2012


Hi Hal, Elena,

> Does anybody have any comments or suggestions? Otherwise I'll commit
> > shortly.
>
> Does this change the non-SSE x86 behavior as well?


The only users of this option at the moment are FMA guards - non-SSE
behavior shouldn't be affected. I've heard it was used to toggle some fp80
options at some point, but it doesn't appear to be used for that these days.


> We should also document this prominently on the clang
> web page (especially if this differs from gcc's default behavior).
>

Agreed.


> Will we have a need for the existing patterns, or should they all
> be rewritten in terms of fma and fneg?


I had a quick look - I think the existing patterns will be redundant when
this patch lands. You'll want to switch to fma + fneg patterns as you
suggested.

You'll also need to override TargetLowering::isFMAFasterThanMulAndAdd.

I'll give you a heads up when I commit this so you can make the changes.


> Whatever you call it, just make sure that fast-math turns it on ;)
>

Sounds good to me.


> On X86 will need to translate ISD::FMA + ISD:NEG to FMSUB or FMNADD
> instructions. And it should be in td file.


Absolutely. This patch is orthogonal to that work - this will form the FMA
+ FNEG, and we can add patterns to the TD files to match those to the X86
FMA instructions.

- Lang.

On Tue, Jun 19, 2012 at 6:04 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> On Tue, 19 Jun 2012 12:01:54 +0000
> "Demikhovsky, Elena" <elena.demikhovsky at intel.com> wrote:
>
> > On X86 will need to translate ISD::FMA + ISD:NEG to FMSUB or FMNADD
> > instructions. And it should be in td file.
>
> True. If that was meant to be an answer to my question, let me clarify:
> My understanding was that excess precision was enabled by default so
> that when using the x87 floating-point instructions, we can do multiple
> consecutive operations without specifically rounding after each one. If
> DisableExcessFPPrecision has now become AllowExcessFPPrecision (which
> is now off by default), has that changed?
>
> Thanks again,
> Hal
>
> >
> > - Elena
> > -----Original Message-----
> > From: llvm-commits-bounces at cs.uiuc.edu
> > [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel
> > Sent: Tuesday, June 19, 2012 07:59 To: Lang Hames
> > Cc: Stephen at dcs-maillist.cs.uiuc.edu; Commit Messages and Patches for
> > LLVM Subject: Re: [llvm-commits] [PATCH] Aggressive FMA formation
> > mode.
> >
> > On Mon, 18 Jun 2012 20:41:56 -0700
> > Lang Hames <lhames at gmail.com> wrote:
> >
> > > Hi All,
> > >
> > > Attached is a patch to aggressively form FMAs from pairs of mul+add
> > > and mul+sub instructions during DAG combine. It forms these
> > > instructions when: (a) AllowExcessFPPrecision is true*.
> > > (b) FMA is legal for the target.
> > > (c) FMA is cheaper than a separate mul and add.
> > >
> > > * I've hijacked and renamed "DisableExcessFPPrecision" for this
> > > patch (new llc command line option: -enable-excess-fp-precision).
> > > The comments for that DisableExcessFPPrecision suggest that this
> > > was its intended purpose. Under my patch the option still defaults
> > > to false, so aggressive FMA formation is now OFF by default.
> > > Previously the ARM and PPC targets had been forming FMAs
> > > aggressively where the instructions were available (at least on
> > > non-Darwin platforms).
> > >
> > > Does anybody have any comments or suggestions? Otherwise I'll
> > > commit shortly.
> >
> > Does this change the non-SSE x86 behavior as well?
> >
> > >
> > > Hal - I've updated the guards on FMA formation for PPC, but by
> > > default FMAs will no longer be formed. If this is a problem, would
> > > it be possible to have your FMA-formation guard rely on a PPC
> > > specific "disable-FMA" option? I'd like to keep
> > > AllowExcessFPPrecision as the guard for target independent FMA
> > > formation, and that should be off by default.
> >
> > We can have it off by default. In the name of having a uniform policy
> > which defaults to IEEE compliance, that's fine, and I can explain
> > that to my users, etc. We should also document this prominently on
> > the clang web page (especially if this differs from gcc's default
> > behavior).
> >
> > Will we have a need for the existing patterns, or should they all be
> > rewritten in terms of fma and fneg?
> >
> > >
> > > - Lang.
> > >
> > > p.s Will be adding a clang command line option for this just as
> > > soon as I work out what to call it. Taking suggestions...
> >
> > Whatever you call it, just make sure that fast-math turns it on ;)
> >
> > Thanks again,
> > Hal
> >
> > --
> > Hal Finkel
> > Postdoctoral Appointee
> > Leadership Computing Facility
> > Argonne National Laboratory
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> >
>
>
>
> --
> Hal Finkel
> Postdoctoral Appointee
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120619/4c718219/attachment.html>


More information about the llvm-commits mailing list