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 <[email protected]> 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> >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
