[PATCH] D46276: [CostModel][X86] Derive TTI costs from complete scheduling models (PR36550) (RFC)

[Simon Pilgrim via Phabricator via llvm-commits]

RKSimon added inline comments.


================
Comment at: lib/Target/X86/X86TargetTransformInfo.cpp:698-716
+    { ISD::FADD,  MVT::v8f32,   2, { X86::VADDPSYrr } },
+    { ISD::FADD,  MVT::v2f64,   1, { X86::VADDPDrr } },
+    { ISD::FADD,  MVT::v4f32,   1, { X86::VADDPSrr } },
+    { ISD::FADD,  MVT::f64,     1, { X86::VADDSDrr } },
+    { ISD::FADD,  MVT::f32,     1, { X86::VADDSSrr } },
+
+    { ISD::FSUB,  MVT::v4f64,   2, { X86::VSUBPDYrr } },
----------------
ABataev wrote:
> andreadb wrote:
> > I wonder if these cost tables  could be auto-generates. For example via tablegen.
> > 
> > ```
> > class CostTableTransition<MVT, list<Instruction>, int DefaultCost = 1> {...};
> > class CostTableEntry<ISDOpcode, list<CostTableTransition>> {...};
> > 
> > def FMUL : ConstTableEntry<
> >   ISD::FMUL,
> >   [
> >     MVT::v4f64, [ X86::VMULPDYrr ],
> >     MVT::v8f32, [ X86::VMULPSYrr ],
> >     ...
> >   ]>
> > >;
> > ```
> > 
> > That being said, I am not convinced that it is a good idea to do it.
> > It is probably a lot of work for very little gain in return. Also, it is questionable whether tablegen descriptors would be more readable and less verbose than what you have here...
> > 
> +1 here
I agree that its getting very cluttered, so I'm open to ideas on how we improve the clarity of the cost tables in the future. But I'm not certain yet if a tblgen refactor will give us much extra benefit.

I'd prefer to get this patch in first to demonstrate how we want to drive the costs from MI and scheduler models.


Repository:
  rL LLVM

https://reviews.llvm.org/D46276