[PATCH] D44519: Add llvm-exegesis tool.

Tue Apr 3 03:50:55 PDT 2018

courbet added a comment.

In https://reviews.llvm.org/D44519#1055406, @andreadb wrote:

> The major problem I see is that the tool expects perf event "UNHALTED_CORE_CYCLES" to be always available. However, that event is Intel specific.
>  I tried to manually change it to something meaningful for my system. However, it would be really nice if we find a way to abstract "generic perf events".
>  For example, we could have the "generic cpu clock" event, which targets/subtargers can define as a alias for a specific hw event type. So, on Intel chips, that "generic cpu clock" event would be wired to UNHALTED_CORE_CYCLES. Is there a plan for doing it?

If you look at the code where the event is defined, there is a TODO to get the name of the event from the sched model (or resource Resource Unit for uops). Our plan is to add the name of the counters to use as an optional property of the SchedModel in TD files.

> The other problem is the dependency with libpfm. At the moment, this is not a big deal for people that work on linux. I don't know if there is an equivalent library for windows. However, if I remember correctly, libpfm builds on top of the linux perf events.  Is there a plan to get rid of that dependency?

The dependency is optional. People who do not have libpfm get an error message when trying to use llvm-exegesis for now. Libpfm is supposed to be available on windows, though I have absolutely no knowledge of how LLVM finds its dependencies on windows. I don;t think it's an issue in the short term since CPUs (hopefully :)) behave the same under all OSes, but I agree that it would be a ice to have.

> Overally, I really like the tool and the goals that it plans to achieve.
>  At the moment, my concern is that the tool is limited to a very specific system and CPU family.
>  So, I am okay with this patch as long as there is a plan to remove the dependency with cpu vendor specific hardware perf events (at least in the medium term).

Definitely, see my answer above.

Repository:
  rL LLVM

https://reviews.llvm.org/D44519