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
float f(float a, float b, float c) {
return c + a * b;
}
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
