[PATCH] D36335: Add ‘llvm.experimental.constrained.fma‘ Intrinsic

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added inline comments.


================
Comment at: lib/Target/X86/X86ISelDAGToDAG.cpp:2015
   default: break;
+  case ISD::FMA: {
+    SDValue ISDFMA = CurDAG->getNode(X86ISD::FMADD, SDLoc(Node),
----------------
wdng wrote:
> andrew.w.kaylor wrote:
> > wdng wrote:
> > > andrew.w.kaylor wrote:
> > > > Can you explain why this was necessary?  I would have expected there to have been handling already in place for ISD::FMA.
> > > No it doesn't, looks like X86 doesn't handle ISD:FMA automatically unless we there is -mattr=+fma option. Without this, CodeGen/X86/fp-intrinsics.ll will fail in instruction selection.
> > I still don't understand.  What happens when -mattr=+fma is used?
> > 
> > The CodeGen/X86/fma.ll test uses that option.  This case should work in the same way.
> I think I made a mistake when describing the problem in my early comments. Let me rephrase and explain it there.
> 
> 1. Without -mattr=+fma, a FMA libcall will be generated
> 2. With -mattr=+fma, we are expecting the corresponding FMA instruction to be generated.
> 
> In fma.ll, all fma tests are *not* constrained fp operations, during the during the X86ISelLowering phase, the FMA node has been lowered to X86ISD::FMADD. So there is no ISD::FMA at this phase since it has already been changed to X86ISD::FMADD before the instruction selection starts. Please refer to the following dump.
> 
> ```
> (gdb) p CurDAG->dump()
> SelectionDAG has 12 nodes:
>   t0: ch = EntryToken
>       t2: f64,ch = CopyFromReg t0, Register:f64 %vreg0
>       t4: f64,ch = CopyFromReg t0, Register:f64 %vreg1
>       t6: f64,ch = CopyFromReg t0, Register:f64 %vreg2
>     t12: f64 = X86ISD::FMADD t2, t4, t6
>   t10: ch,glue = CopyToReg t0, Register:f64 %XMM0, t12
>   t11: ch = X86ISD::RET_FLAG t10, TargetConstant:i32<0>, Register:f64 %XMM0, t10:1
> 
> ```
> However, for the constrained fma, we use mutateStrictFPToFP( ) function to mutate constrained_fma to normal fma, namely ISD::FMA before the instruction selction starts. The X86 backend cannot recognize the ISD::FMA, so we have to add codes to convert ISD::FMA to X86ISD::FMADD during the instruction selection. 
> 
>  
I'm still not sure I understand this, but it sounds to me like this should be happening somewhere else.

Are you saying that if -mattr=+fma is not used the ISD::STRICT_FMA will be expanded to a libcall before we reach mutateStrictFpToFP and so this code will never be reached in that case?  And if so, are you further saying that when -mattr=+fma is used we will reach this code only after mutateStrictFpToFp() has converted ISD::STRICT_FMA to ISD::FMA?

My concern is that this is adding a generic (not constrained-specific) handler to handle the constrained case.  I would much rather figure out a way to get ISD::STRICT_FMA to follow the existing path.


Repository:
  rL LLVM

https://reviews.llvm.org/D36335