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

[Andrea Di Biagio via Phabricator via llvm-commits]

andreadb added a comment.

>>> 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 !

I agree. You don't want to do that..
I was just curious. I guess, this is not going to hurt me since I mostly develop on linux. Also, based on this: http://perfmon2.sourceforge.net/ I think I should be able to get support for Jaguar (which is the cpu I mostly care about) and other AMD chips.

> 
> 
>> 
>> 
>>> 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).

Cool. Thanks Clement :-)


Repository:
  rL LLVM

https://reviews.llvm.org/D45360