[LLVMdev] Documentation of fmuladd intrinsic

[Cameron McInally]

On Fri, Jan 11, 2013 at 1:08 PM, Andrew Booker <andrew.booker at arm.com>wrote:

> The fmuladd intrinsic is described as saying that a multiply and
> addition sequence can be fused into an fma instruction "if the code
> generator determines that the fused expression would be legal and
> efficient". (http://llvm.org/docs/LangRef.html#llvm-fma-intrinsic)
>
> I've spent a bit of time puzzling over how a code generator is supposed
> to know if it's legal to generate an fma instead of a multiply and add
> - surely that's something for the frontend to determine, based on the
> FP_CONTRACT setting, and not something for the code generator to work
> out?
>
> However, recently I came across
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120528/0582
> 22.html
> which explains that "legal" in the above definition doesn't mean legal
> from the point of view of the source language, but simply means whether
> or not the target architecture has an fma instruction. The thread also
> talks about updating the documentation to clarify this, but that
> doesn't seem to have happened.
>
> Assuming that the thread I've linked to is correct, would it be
> possible to clarify the IR spec accordingly? I think that the current
> use of the word "legal" is misleading.
>
>
Hey Andrew,

I believe that the term "legal" is associated with the Legalize phase.
Please see:

http://llvm.org/docs/CodeGenerator.html#selectiondag-legalize-phase

The x86 backend has a good example of this
in llvm/lib/Target/X86/X86ISelLowering.cpp:

>  if (Subtarget->hasFMA()) {
>    // Support FMAs!
>    setOperationAction(ISD::FMA, MVT::f64, Legal);
>    setOperationAction(ISD::FMA, MVT::f32, Legal);
>  }
>  else {
>    // We don't support FMA.
>    setOperationAction(ISD::FMA, MVT::f64, Expand);
>    setOperationAction(ISD::FMA, MVT::f32, Expand);
>  }


Hope that helps,
Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/06575ce6/attachment.html>