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

[Chandler Carruth]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120615/1d1743eb/attachment.html>