[llvm-commits] [llvm] r158014 - in /llvm/trunk: docs/LangRef.html include/llvm/Intrinsics.td include/llvm/Target/TargetLowering.h lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp

Chris Lattner clattner at apple.com
Sat Jun 16 19:13:58 PDT 2012


On Jun 15, 2012, at 1:51 PM, Chandler Carruth wrote:

> On Fri, Jun 15, 2012 at 10:04 AM, Chris Lattner <clattner at apple.com> wrote:
> On Jun 9, 2012, at 9:51 PM, Hal Finkel wrote:
> > On Tue, 05 Jun 2012 19:07:46 -0000 Lang Hames <lhames at gmail.com> wrote:
> >> Author: lhames
> >> Date: Tue Jun  5 14:07:46 2012
> >> New Revision: 158014
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=158014&view=rev
> >> Log:
> >> Add a new intrinsic: llvm.fmuladd. This intrinsic represents a
> >> multiply-add expression (a * b + c) that can be implemented as a
> >> fused multiply-add (fma) if the target determines that this will be
> >> more efficient. This intrinsic will be used to implement FP_CONTRACT
> >> support and an aggressive FMA formation mode.
> >>
> >> If your target has a fast FMA instruction you should override the
> >> isFMAFasterThanMulAndAdd method in TargetLowering to return true.
> >
> >
> > Will this apply (or be extended) to other contractions as well (like a *
> > b - c) [fmsub on PowerPC].
> 
> It doesn't, and can't reasonably be extended to support it.  However, it is progress that does help a number of other targets and can be upgraded to be more general if someone is motivated to do it.
> 
> If you are interested, here's a possible sketch of an approach that could handle the more general cases (including subtract, random negations, etc):
> 
> 1. Add two bits (like NSW/NUW on integer ops) to the floating point binary operations (fmul, fadd, ...): LHS_Contractable and RHS_Contractable.
> 
> 2. Semantics are that the code generator is allowed to contract any tree of operations linked through "contractable" operands.  In the FMA case, the multiply can be merged into the add if the add's operand is marked contractable.  In the PPC case, fmsub can be contracted if the multiply operand of the subtract is marked.
> 
> 3. Clang would generate the operand bits according to the language mode in effect.  I believe that this model is sufficiently general to handle the C99 and C++ cases.
> 
> I filed PR13118 to track this if you're interested.
> 
> Yes, please.
> 
> Also Chris, you should read the lengthy review thread for this patch. Steve, myself, and John McCall discussed lots of different options here, and John had an alternative to yours that also preserved the generality... I'm not sure which approach is best, so I'd love your thoughts on the two. 

They are semantically equivalent (and mine is inspired by his).  The major difference is that mine won't block a bunch of optimizations by introducing a "copy" that has to be looked through, and mine follows the pattern established by the NUW/NSW bits on integer operations.  At this point, it makes sense to move further discussion to PR13118.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120616/833b8d5e/attachment.html>


More information about the llvm-commits mailing list