[llvm-dev] [RFC] llvm-exegesis: Automatic Measurement of Instruction Latency/Uops

Clement Courbet via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 15 09:20:53 PDT 2018


On Thu, Mar 15, 2018 at 5:12 PM, Eric Christopher <echristo at gmail.com>
wrote:

> I am, of course, a huge fan of this effort. :)
>
>>
>>>
>>>    -
>>>
>>>    [??] Make the tool work for other CPUs. This mainly depends on the
>>>    presence of performance counters.
>>>
>>> Having these requirements documented will be great. In particular, it's
> important to document what kind of functionality we need out of the PMU
> rather than any particular cpu specific counter. Also performance
> requirements of the counters.
>

I'll create a bug to track that as soon as the RFC has been accepted. In a
nutshell we were thinking of adding a field to `ProcResource` in
`TargetSchedule.td` that maps the resource to a (list of) pfm/perf event,
and let libpfm abstract the hardware for us.


>
>
> Open Questions We depend on libpfm
>>> <http://perfmon2.sourceforge.net/docs_v4.html>. How do we handle the
>>> dependency ?
>>>
>>>
>>> Are there options that you have in mind? It's an external MIT-licensed
>>> dependency. Wouldn't CMake just detect it when it's available?
>>>
>>
>> That's what we've done for now (see code here
>> <https://reviews.llvm.org/differential/changeset/?ref=1002469&whitespace=ignore-most>).
>> We're not sure what the policy is wrt external deps. Right now if the tool
>> is enabled and libpfm is not on the system, we die with an error message.
>> The other options would be to disable the tool in that case (I'm not sure
>> how to do that). Opinions ?
>>
>>
>> Sounds good (we can discuss this further, if necessary, in the code
>> review).
>>
>
> Agreed. :)
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180315/7ace6aac/attachment.html>


More information about the llvm-dev mailing list