Hi Tobias,<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Lang.<br><br><div class="gmail_quote">On Tue, Jul 24, 2012 at 1:05 PM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 05/30/2012 05:41 AM, Lang Hames wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi All,<br>
<br>
I guess it's better to CC both lists, rather than have parallel feedback<br>
on these patches - so for the Clang people who haven't seen this yet:<br>
<br>
I want to improve Clang/LLVM's support for the fp_contract pragma.<br>
(Background: when the fp_contract pragma is ON, multiplications and<br>
additions within expressions can be fused to FMAs. This is a performance<br>
win on targets that have a fast fma instruction.)<br>
<br>
As a step towards implementing this functionality, these patches add a<br>
new family of intrinsics, llvm.fmuladd.*, that represent mul+add<br>
expressions that can be fused. Clang will emit calls to these intrinsics<br>
when it sees a mul+add in a single source expression and fp_contract is<br>
ON. During LLVM isel, the legalizer will check the<br>
Subtarget::isFMACheap() method to decide whether to lower these<br>
intrinsics to llvm.fma.* intrinsic calls, or a regular unfused mul and<br>
add expression.<br>
<br>
The attached clang patch adds a per-function flag to FunctionDecl that<br>
records the state of the fp_contract pragma when each function is<br>
defined, and passes this information down to codegen. Clang codegen can<br>
then emit calls to the new llvm.fmuladd intrinsic, instead of plain mul<br>
+ add instructions.<br>
</blockquote>
<br></div></div>
Hi Lang,<br>
<br>
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.<br>

(Using clang -cc1 -S -emit-llvm -O3 /tmp/test.c -ffp-contract=on)<br>
<br>
I looked through the FMA related discussions and the last point I could find was this text from you:<div class="im"><br>
<br>
"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."<br>

<br></div>
Could you explain the reason it did not go in? Did you choose a different solution?<br>
<br>
Cheers<br>
Tobi<br>
<br>
[1] <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120604/144130.html" target="_blank">http://lists.cs.uiuc.edu/<u></u>pipermail/llvm-commits/Week-<u></u>of-Mon-20120604/144130.html</a><br>
</blockquote></div><br></div>