This is an archive of the discontinued LLVM Phabricator instance.

[llvm-mca] Add pipeline stall events.
ClosedPublic

Authored by andreadb on Mar 19 2018, 4:06 AM.

Details

Summary

This patch introduces a new class named HWStallEvent (see HWEventListener.h), and updates the event listener interface. A HWStallEvent represents a pipeline stall caused by the lack of hardware resources. Similarly to HWInstructionEvent, the event type is an unsigned, and the exact meaning depends on the subtarget.
At the moment, HWStallEvent supports a few generic dispatch events.

The main goals of this patch is to remove the logic that counts dispatch stalls from the DispatchUnit to the BackendStatistics view.

Previously, DispatchUnit was responsible for counting and classifying dispatch stall events. With this patch, we delegate the task of counting and classifying stall events to the listeners (i.e. in our case, it is view "BackendStatistics"). So, the DispatchUnit doesn't have to do extra (unnecessary) bookkeeping.

This patch also helps futher simplifying the Backend interface. Now class BackendStatistics no longer has to query the Backend interface to obtain the number of dispatch stalls. As a consequence, we can get rid of all the 'getNumXXX()' methods from class Backend.
The long term goal is to remove all the remaining dependencies between the Backend and the BackendStatistics interface.

No functional change intended.

Diff Detail

Repository
rL LLVM

Event Timeline

andreadb created this revision.Mar 19 2018, 4:06 AM
courbet accepted this revision.Mar 19 2018, 5:30 AM

Only minor nits, otherwise LGTM.

tools/llvm-mca/Dispatch.cpp
289 ↗(On Diff #138891)

Any reason not to inline this ?

301 ↗(On Diff #138891)

ditto

This revision is now accepted and ready to land.Mar 19 2018, 5:30 AM
andreadb added inline comments.Mar 19 2018, 5:37 AM
tools/llvm-mca/Dispatch.cpp
289 ↗(On Diff #138891)

Not really... If I remember correctly, the statement was still using two lines (due to the 80-col). When I wrote this patch, I thought it was probably more readable if I did split it into two statements.
That being said, I am okay with inlining it. I will fix it (and the other case).

This revision was automatically updated to reflect the committed changes.