[PATCH] D45360: [MC][TableGen] Add optional libpfm counter names for ProcResUnits.

Clement Courbet via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Apr 6 07:09:05 PDT 2018


courbet added a comment.

In https://reviews.llvm.org/D45360#1059678, @courbet wrote:

> Let's summarize what we need and how we can address those needs.
>
> For each subtarget, we need to know:
>
> - How to count cycles.
> - How to count uops issued on each resource.
>
>   There are two orthogonal technical aspects to decide on, which are how to name the counters, and where to store the mapping from subtarget/procres to abstract counter
>
>   As for naming counters, the options that have been cited up to now are: 1 - (this design and Andrea's proposal) counters are identified by an abstract string (I happened to pick the libpfm convention, because that's the lib we've used). 2 - (raw counters) counters are identified by the architecture-specific id, which is an int on Intel but could be a something else on other architectures.
>
>   I think that (1) is as good as (2), because (2) will have to be something complex to handle all microarchitectures, so I'd rather leave this complexity to be dealt with by libpfm, which was designed for this very purpose.
>
>   As for storing the mapping, the options that have been cited up to now are: A - (this design) counters are a property of the class they semantically relate to. B - (Andrea's proposal) the mapping is a separate table of pairs of (counter, class it semantically relates to) C - (Simon's proposal 2) the mapping is a separate config file. I believe this to be a variation of (B) where the table is stored in a different file. D - (Simon's proposal 1) the mapping is hardcoded in llvm-exegesis.


Reflecting on this a bit more:

Option (B) has the advantage that the information is not stored alongside either resources or model but in a separate "table" (using relational language). That has the advantage that it imposes no specific place where the information has to be stored (which nicely fits with (C)).
Then (B) is simply "store the mapping for subtarget XYZ into file X86SchedXYZ.td" , which (C) is "store all mappings into a separate X86Counters.td"

As for (D), I'm very much opposed to storing anything outside of the TD files, because that would mean that we loose the advantage of all the object resolution done in SubtargetEmitter, so it would be very hard to maintain.


Repository:
  rL LLVM

https://reviews.llvm.org/D45360





More information about the llvm-commits mailing list