[all-commits] [llvm/llvm-project] f7a23e: [MCA] Adding the CustomBehaviour class to llvm-mca

[Patrick Holland via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f7a23ecece524564a0c3e09787142cc6061027bb
      https://github.com/llvm/llvm-project/commit/f7a23ecece524564a0c3e09787142cc6061027bb
  Author: Patrick Holland <patrickeholland at gmail.com>
  Date:   2021-06-15 (Tue, 15 Jun 2021)

  Changed paths:
    M llvm/docs/CommandGuide/llvm-mca.rst
    M llvm/include/llvm/MCA/Context.h
    A llvm/include/llvm/MCA/CustomBehaviour.h
    M llvm/include/llvm/MCA/HWEventListener.h
    M llvm/include/llvm/MCA/Instruction.h
    M llvm/include/llvm/MCA/Stages/InOrderIssueStage.h
    M llvm/lib/MCA/CMakeLists.txt
    M llvm/lib/MCA/Context.cpp
    A llvm/lib/MCA/CustomBehaviour.cpp
    M llvm/lib/MCA/InstrBuilder.cpp
    M llvm/lib/MCA/Stages/InOrderIssueStage.cpp
    M llvm/tools/llvm-mca/CMakeLists.txt
    M llvm/tools/llvm-mca/Views/DispatchStatistics.cpp
    A llvm/tools/llvm-mca/lib/AMDGPU/AMDGPUCustomBehaviour.cpp
    A llvm/tools/llvm-mca/lib/AMDGPU/AMDGPUCustomBehaviour.h
    A llvm/tools/llvm-mca/lib/AMDGPU/CMakeLists.txt
    A llvm/tools/llvm-mca/lib/CMakeLists.txt
    M llvm/tools/llvm-mca/llvm-mca.cpp

  Log Message:
  -----------
  [MCA] Adding the CustomBehaviour class to llvm-mca

Some instructions are not defined well enough within the target’s scheduling
model for llvm-mca to be able to properly simulate its behaviour. The ideal
solution to this situation is to modify the scheduling model, but that’s not
always a viable strategy. Maybe other parts of the backend depend on that
instruction being modelled the way that it is. Or maybe the instruction is quite
complex and it’s difficult to fully capture its behaviour with tablegen. The
CustomBehaviour class (which I will refer to as CB frequently) is designed to
provide intuitive scaffolding for developers to implement the correct modelling
for these instructions.

Implementation details:

llvm-mca does its best to extract relevant register, resource, and memory
information from every MCInst when lowering them to an mca::Instruction. It then
uses this information to detect dependencies and simulate stalls within the
pipeline. For some instructions, the information that gets captured within the
mca::Instruction is not enough for mca to simulate them properly. In these
cases, there are two main possibilities:

1. The instruction has a dependency that isn’t detected by mca.
2. mca is incorrectly enforcing a dependency that shouldn’t exist.

For the rest of this discussion, I will be focusing on (1), but I have put some
thought into (2) and I may revisit it in the future.

So we have an instruction that has dependencies that aren’t picked up by mca.
The basic idea for both pipelines in mca is that when an instruction wants to be
dispatched, we first check for register hazards and then we check for resource
hazards. This is where CB is injected. If no register or resource hazards have
been detected, we make a call to CustomBehaviour::checkCustomHazard() to give
the target specific CB the chance to detect and enforce any custom dependencies.

The return value for checkCustomHazaard() is an unsigned int representing the
(minimum) number of cycles that the instruction needs to stall for. It’s fine to
underestimate this value because when StallCycles gets down to 0, we’ll end up
checking for all the hazards again before the instruction is actually
dispatched. However, it’s important not to overestimate the value and the more
accurate your estimate is, the more efficient mca’s execution can be.

In general, for checkCustomHazard() to be able to detect these custom
dependencies, it needs information about the current instruction and also all of
the instructions that are still executing within the pipeline. The mca pipeline
uses mca::Instruction rather than MCInst and the current information encoded
within each mca::Instruction isn’t sufficient for my use cases. I had to add a
few extra attributes to the mca::Instruction class and have them get set by the
MCInst during instruction building. For example, the current mca::Instruction
doesn’t know its opcode, and it also doesn’t know anything about its immediate
operands (both of which I had to add to the class).

With information about the current instruction, a list of all currently
executing instructions, and some target specific objects (MCSubtargetInfo and
MCInstrInfo which the base CB class has references to), developers should be
able to detect and enforce most custom dependencies within checkCustomHazard. If
you need more information than is present in the mca::Instruction, feel free to
add attributes to that class and have them set during the lowering sequence from
MCInst.

Fortunately, in the in-order pipeline, it’s very convenient for us to pass these
arguments to checkCustomHazard. The hazard checking is taken care of within
InOrderIssueStage::canExecute(). This function takes a const InstRef as a
parameter (representing the instruction that currently wants to be dispatched)
and the InOrderIssueStage class maintains a SmallVector<InstRef, 4> which holds
all of the currently executing instructions. For the out-of-order pipeline, it’s
a bit trickier to get the list of executing instructions and this is why I have
held off on implementing it myself. This is the main topic I will bring up when
I eventually make a post to discuss and ask for feedback.

CB is a base class where targets implement their own derived classes. If a
target specific CB does not exist (or we pass in the -disable-cb flag), the base
class is used. This base class trivially returns 0 from its checkCustomHazard()
implementation (meaning that the current instruction needs to stall for 0 cycles
aka no hazard is detected). For this reason, targets or users who choose not to
use CB shouldn’t see any negative impacts to accuracy or performance (in
comparison to pre-patch llvm-mca).

Differential Revision: https://reviews.llvm.org/D104149