[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 } },
----------------
RKSimon wrote:
> 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.
We will also need a plan for PR31274 before we consider a move to tblgen or other big changes.


Repository:
  rL LLVM

https://reviews.llvm.org/D46276