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

[Lang Hames]

Hi Tobias,

The feedback from the clang community at the time was that my approach to
tracking the FP_CONTRACT pragma state wasn't ideal, so I've held off
committing until I had a better solution. Unfortunately I've been
sidetracked by other work at the moment, but I hope to get back to this
some time in the coming weeks.

Cheers,
Lang.

On Tue, Jul 24, 2012 at 1:05 PM, Tobias Grosser <tobias at grosser.es> wrote:

> 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<http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120604/144130.html>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120724/39e3a2c4/attachment.html>