[PATCH] D52932: [MCSched] Bind PFM Counters to the CPUs instead of the SchedModel.

Mon Oct 22 07:25:02 PDT 2018

courbet added a subscriber: lebedev.ri.
courbet added a comment.

In https://reviews.llvm.org/D52932#1270595, @RKSimon wrote:

> It looks like we need to find a way to still embed this information in MCExtraProcessorInfo but allow for different CPUs PFM mappings.
>  Can you easily attach PFM mappings to the GenericModel/GenericPostRAModel?

I don't think an `MCExtraProcessorInfo` should store information for several CPUs, because `MCExtraProcessorInfo` is in `MCSchedModel`, which is selected by CPU, so that would be weird.

Before this change, we were putting the `MCPfmCountersInfo` inside `MCSchedModel`, which implicitly meant that there was a 1:1 mapping between them. This change decouples `MCPfmCountersInfo` from `MCSchedModel`.
A CPU chooses its SchedModel and PfmCounters independently.

Now the decision we have to make now is whether in TD files (see point (2) in my comment above):

- (A) the CPU should declare its PfmCounters (this is the approach I'm taking here). Because that's very similar to what is done for `MCSchedModel`s, I'm doing the same for  PfmCounters, i.e. putting the table of Cpu->PfmCounter inside `TargetSubtargetInfo`, but that is actually independent from (see point (1) in my  response to Andrea's comment above)
- (B) the mapping of CPU->PfmCounter is kept separately (in `X86PfmCounters.td`).

> One of the aims for PR39165 was to make it possible for llvm-exegesis to be run on CPUs with declared PFMs but without a model - allowing a report on raw resource usage for an instruction and to help create the model from scratch. @courbet @gchatelet do you think this would still be useful? 
>  Is it still an aim of llvm-exegesis to create models from scratch or just report on existing models?

@lebedev.ri used llvm-exegesis to produce the bdverX model. At that point there was no SchedModel, so it still seems desirable to do this.

Repository:
  rL LLVM

https://reviews.llvm.org/D52932