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

Demikhovsky, Elena elena.demikhovsky at intel.com
Tue Jun 19 05:01:54 PDT 2012


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

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





More information about the llvm-commits mailing list