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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added inline comments.


================
Comment at: lib/Target/X86/X86TargetTransformInfo.cpp:658
+  static const SchedCostTblEntry AVX1CostTable[] = {
+    { ISD::FADD,  MVT::v4f64,   2, { X86::VADDPDYrr } },
+    { ISD::FADD,  MVT::v8f32,   2, { X86::VADDPSYrr } },
----------------
efriedma wrote:
> RKSimon wrote:
> > RKSimon wrote:
> > > craig.topper wrote:
> > > > craig.topper wrote:
> > > > > Is this going to cause a bunch of SmallVectors to be constructed at startup? I think that goes against our coding standards.
> > > > Or will it only happen the first time this function runs?
> > > Thanks for reminding me - first time only but using SmallVector was a quick fix to get around ArrayRef not working properly after the first time for some reason that I didn't investigate thoroughly. IIRC moving the tables out of the functions and into global namespace fixed the issue.
> > Update: I haven't found a way to avoid having to use SmallVector to create the code sequences, including if I move the tables into the global namespace - all approaches I've tried seem to have constexpr issues with initialization at compile time - mainly as the sequences appear as std::initializer_list - I'm open to suggestions........
> ```
> struct C { const int (&x)[6]; };
> extern const C z = { { 1, 2, 3 } };
> ```
> 
> The hardcoded number of array elements is a bit ugly, but I'm not sure there's any standard alternative.
Actually, the following should do the right thing:

```
#include <initializer_list>
struct C { const std::initializer_list<unsigned> &x; };
int f(int i) {
  static const C z = { { 1, 2, 3 } };
  return z.x.begin()[i];
}
```

gcc versions older than 5.0 apparently have a bug where the initalizer isn't considered a constant, but it still emits the right code.


Repository:
  rL LLVM

https://reviews.llvm.org/D46276