[PATCH] D127083: [MCA] Introducing incremental SourceMgr and resumable pipeline

Andrea Di Biagio via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 6 10:08:26 PDT 2022


andreadb added a comment.

Hi Min,

Thanks for this patch. I have just started looking at it. I left a few comments inline.

Thanks!



================
Comment at: llvm/include/llvm/MCA/Pipeline.h:54
 
+  enum State {
+    S_Created = 0, // Pipeline was just created. The default state.
----------------
Can you use an `enum class` here?


================
Comment at: llvm/include/llvm/MCA/SourceMgr.h:26-29
 
-class SourceMgr {
+/// Abstracting the input code sequence (a sequence of MCInst) and assigning
+/// unique identifiers to every instruction in the sequence.
+struct SourceMgr {
----------------
This is not ideal, but I can't think of any other obvious way to avoid this refactoring.

Did you notice a perf regression after this change on normal llvm-mca runs with several iterations?

I wonder if you could make SourceMgr a template class, and have it specialised based on whether you want a "circular buffer" behaviour or not.

Ideally, `class SourceMgr` should only be visible to the so-called pipeline entry stage(s). In llvm-mca there are two default entry stages: `EntryStage` (for the out-of-order pipeline) and `InOrderIssueStage` (for the in-order pipeline). Any other module should not use SourceMgr; for those modules, the input assembly sequence can often be easily abstracted using an ArrayRef<MCInst>. This is for example what we do in some Views.

That being said, I am seeing uses of `SourceMgr` in the `CustomBehaviour` API. For example, AMDGPU uses a `CustomBehaviour` to get access to the immutable MCInst sequence and simply iterate over the MCInst. This might have been an oversight/poor design choice from our end, since we don't seem to really need any of the extra SourceMgr functionalities in CustomBehaviour. In fact, passing an ArrayRef<MCInst> would be enough (at least for the AMDGPU).
'
In retrospect, I wonder whether there was a reason for that choice.
@holland11 Would it cause problems if we changed the CustomBehaviour constructor so that it accepts an ArrayRef<MCInst> instead of a SourceMgr? Do you remember why we needed it?


================
Comment at: llvm/include/llvm/MCA/SourceMgr.h:32-34
+  /// Provides a fixed range of \a UniqueInst to iterate.
+  virtual ArrayRef<UniqueInst> getInstructions() const = 0;
+
----------------
Is there a reason why you want to add this method?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127083/new/

https://reviews.llvm.org/D127083



More information about the llvm-commits mailing list