[cfe-commits] [llvm-commits] [PATCH] Add llvm.fmuladd intrinsic.

[Tobias Grosser]

On 05/30/2012 05:41 AM, Lang Hames wrote:
> Hi All,
>
> I guess it's better to CC both lists, rather than have parallel feedback
> on these patches - so for the Clang people who haven't seen this yet:
>
> I want to improve Clang/LLVM's support for the fp_contract pragma.
> (Background: when the fp_contract pragma is ON, multiplications and
> additions within expressions can be fused to FMAs. This is a performance
> win on targets that have a fast fma instruction.)
>
> As a step towards implementing this functionality, these patches add a
> new family of intrinsics, llvm.fmuladd.*, that represent mul+add
> expressions that can be fused. Clang will emit calls to these intrinsics
> when it sees a mul+add in a single source expression and fp_contract is
> ON. During LLVM isel, the legalizer will check the
> Subtarget::isFMACheap() method to decide whether to lower these
> intrinsics to llvm.fma.* intrinsic calls, or a regular unfused mul and
> add expression.
>
> The attached clang patch adds a per-function flag to FunctionDecl that
> records the state of the fp_contract pragma when each function is
> defined, and passes this information down to codegen. Clang codegen can
> then emit calls to the new llvm.fmuladd intrinsic, instead of plain mul
> + add instructions.

Hi Lang,

I just had a discussion about fmuladd support in clang and stated that 
clang will (in some circumstances) create a llvm.fmuladd intrinsic. 
However, looking into the clang commit logs the patch you sent went 
never in and -fp-contract=on does not create the fmuladd intrinsic for 
the attached test case.
(Using clang -cc1 -S -emit-llvm -O3 /tmp/test.c -ffp-contract=on)

I looked through the FMA related discussions and the last point I could 
find was this text from you:

"My big take-away from discussing this with Chandler is that I didn't 
explain the motivation for the existing design well. I'll keep that in 
mind in future. The reason I like fmuladd as a way to get started on 
FP_CONTRACT support is simply because it's lightweight, and captures 
most of the cases that we care about. The heavy lifting for proper 
FP_CONTRACT support, such as there is, will be teaching the parser how 
to properly deal with FP_CONTRACT pragmas applied to subexpressions 
(This is probably a simple task for people who are familiar with clang, 
but it is new territory for me). Since fmuladd itself is so trivial, it 
will be easy to replace with a more comprehensive system for tracking 
fusing opportunities if/when we decide it's called for."

Could you explain the reason it did not go in? Did you choose a 
different solution?

Cheers
Tobi

[1] 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120604/144130.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 58 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120725/690b063d/attachment.c>