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

[Clement Courbet via Phabricator via llvm-commits]

courbet added a comment.

In https://reviews.llvm.org/D45360#1059732, @andreadb wrote:

> 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.
>
>
> I am a bit confused. Does it mean that exegesis will always have the dependency on libpfm (which means, it would only work on systems that provide it, for the cpus known by the installed lib version on the system)?


It does not *have to*, but until a better solution comes along, yes :) Just peeking at the tables in libpfm to abstract both OS and hardware really makes me want to not have to handle that !

> 
> 
>> 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.
> 
> If D is too complicated, then B or C. I don't want to pollute existing abstractions used by the LLVM schedulers with information which is only used by external tools.
>  I still want to allow targets to be able to strip off (or disable the emission of ) that information if they don't need it.

I'll go with (C).


Repository:
  rL LLVM

https://reviews.llvm.org/D45360