diff options
Diffstat (limited to 'docs/CommandGuide/llvm-mca.rst')
| -rw-r--r-- | docs/CommandGuide/llvm-mca.rst | 238 |
1 files changed, 216 insertions, 22 deletions
diff --git a/docs/CommandGuide/llvm-mca.rst b/docs/CommandGuide/llvm-mca.rst index dd2320b15ffb..e44eb2f8ce9b 100644 --- a/docs/CommandGuide/llvm-mca.rst +++ b/docs/CommandGuide/llvm-mca.rst @@ -114,8 +114,8 @@ option specifies "``-``", then the output will also be sent to standard output. .. option:: -register-file-size=<size> Specify the size of the register file. When specified, this flag limits how - many temporary registers are available for register renaming purposes. A value - of zero for this flag means "unlimited number of temporary registers". + many physical registers are available for register renaming purposes. A value + of zero for this flag means "unlimited number of physical registers". .. option:: -iterations=<number of iterations> @@ -207,23 +207,23 @@ EXIT STATUS :program:`llvm-mca` returns 0 on success. Otherwise, an error message is printed to standard error, and the tool returns 1. -HOW MCA WORKS -------------- +HOW LLVM-MCA WORKS +------------------ -MCA takes assembly code as input. The assembly code is parsed into a sequence -of MCInst with the help of the existing LLVM target assembly parsers. The -parsed sequence of MCInst is then analyzed by a ``Pipeline`` module to generate -a performance report. +:program:`llvm-mca` takes assembly code as input. The assembly code is parsed +into a sequence of MCInst with the help of the existing LLVM target assembly +parsers. The parsed sequence of MCInst is then analyzed by a ``Pipeline`` module +to generate a performance report. The Pipeline module simulates the execution of the machine code sequence in a loop of iterations (default is 100). During this process, the pipeline collects a number of execution related statistics. At the end of this process, the pipeline generates and prints a report from the collected statistics. -Here is an example of a performance report generated by MCA for a dot-product -of two packed float vectors of four elements. The analysis is conducted for -target x86, cpu btver2. The following result can be produced via the following -command using the example located at +Here is an example of a performance report generated by the tool for a +dot-product of two packed float vectors of four elements. The analysis is +conducted for target x86, cpu btver2. The following result can be produced via +the following command using the example located at ``test/tools/llvm-mca/X86/BtVer2/dot-product.s``: .. code-block:: bash @@ -287,10 +287,30 @@ for a total of 900 dynamically executed instructions. The report is structured in three main sections. The first section collects a few performance numbers; the goal of this section is to give a very quick overview of the performance throughput. In this example, the two important -performance indicators are the predicted total number of cycles, and the IPC. -IPC is probably the most important throughput indicator. A big delta between -the Dispatch Width and the computed IPC is an indicator of potential -performance issues. +performance indicators are **IPC** and **Block RThroughput** (Block Reciprocal +Throughput). + +IPC is computed dividing the total number of simulated instructions by the total +number of cycles. A delta between Dispatch Width and IPC is an indicator of a +performance issue. In the absence of loop-carried data dependencies, the +observed IPC tends to a theoretical maximum which can be computed by dividing +the number of instructions of a single iteration by the *Block RThroughput*. + +IPC is bounded from above by the dispatch width. That is because the dispatch +width limits the maximum size of a dispatch group. IPC is also limited by the +amount of hardware parallelism. The availability of hardware resources affects +the resource pressure distribution, and it limits the number of instructions +that can be executed in parallel every cycle. A delta between Dispatch +Width and the theoretical maximum IPC is an indicator of a performance +bottleneck caused by the lack of hardware resources. In general, the lower the +Block RThroughput, the better. + +In this example, ``Instructions per iteration/Block RThroughput`` is 1.50. Since +there are no loop-carried dependencies, the observed IPC is expected to approach +1.50 when the number of iterations tends to infinity. The delta between the +Dispatch Width (2.00), and the theoretical maximum IPC (1.50) is an indicator of +a performance bottleneck caused by the lack of hardware resources, and the +*Resource pressure view* can help to identify the problematic resource usage. The second section of the report shows the latency and reciprocal throughput of every instruction in the sequence. That section also reports @@ -316,7 +336,7 @@ pressure should be uniformly distributed between multiple resources. Timeline View ^^^^^^^^^^^^^ -MCA's timeline view produces a detailed report of each instruction's state +The timeline view produces a detailed report of each instruction's state transitions through an instruction pipeline. This view is enabled by the command line option ``-timeline``. As instructions transition through the various stages of the pipeline, their states are depicted in the view report. @@ -331,7 +351,7 @@ These states are represented by the following characters: Below is the timeline view for a subset of the dot-product example located in ``test/tools/llvm-mca/X86/BtVer2/dot-product.s`` and processed by -MCA using the following command: +:program:`llvm-mca` using the following command: .. code-block:: bash @@ -366,7 +386,7 @@ MCA using the following command: 2. 3 5.7 0.0 0.0 vhaddps %xmm3, %xmm3, %xmm4 The timeline view is interesting because it shows instruction state changes -during execution. It also gives an idea of how MCA processes instructions +during execution. It also gives an idea of how the tool processes instructions executed on the target, and how their timing information might be calculated. The timeline view is structured in two tables. The first table shows @@ -411,12 +431,12 @@ Parallelism). In the dot-product example, there are anti-dependencies introduced by instructions from different iterations. However, those dependencies can be removed at register renaming stage (at the cost of allocating register aliases, -and therefore consuming temporary registers). +and therefore consuming physical registers). Table *Average Wait times* helps diagnose performance issues that are caused by the presence of long latency instructions and potentially long data dependencies -which may limit the ILP. Note that MCA, by default, assumes at least 1cy -between the dispatch event and the issue event. +which may limit the ILP. Note that :program:`llvm-mca`, by default, assumes at +least 1cy between the dispatch event and the issue event. When the performance is limited by data dependencies and/or long latency instructions, the number of cycles spent while in the *ready* state is expected @@ -549,3 +569,177 @@ statistics are displayed by using the command option ``-all-stats`` or In this example, we can conclude that the IPC is mostly limited by data dependencies, and not by resource pressure. + +Instruction Flow +^^^^^^^^^^^^^^^^ +This section describes the instruction flow through MCA's default out-of-order +pipeline, as well as the functional units involved in the process. + +The default pipeline implements the following sequence of stages used to +process instructions. + +* Dispatch (Instruction is dispatched to the schedulers). +* Issue (Instruction is issued to the processor pipelines). +* Write Back (Instruction is executed, and results are written back). +* Retire (Instruction is retired; writes are architecturally committed). + +The default pipeline only models the out-of-order portion of a processor. +Therefore, the instruction fetch and decode stages are not modeled. Performance +bottlenecks in the frontend are not diagnosed. MCA assumes that instructions +have all been decoded and placed into a queue. Also, MCA does not model branch +prediction. + +Instruction Dispatch +"""""""""""""""""""" +During the dispatch stage, instructions are picked in program order from a +queue of already decoded instructions, and dispatched in groups to the +simulated hardware schedulers. + +The size of a dispatch group depends on the availability of the simulated +hardware resources. The processor dispatch width defaults to the value +of the ``IssueWidth`` in LLVM's scheduling model. + +An instruction can be dispatched if: + +* The size of the dispatch group is smaller than processor's dispatch width. +* There are enough entries in the reorder buffer. +* There are enough physical registers to do register renaming. +* The schedulers are not full. + +Scheduling models can optionally specify which register files are available on +the processor. MCA uses that information to initialize register file +descriptors. Users can limit the number of physical registers that are +globally available for register renaming by using the command option +``-register-file-size``. A value of zero for this option means *unbounded*. +By knowing how many registers are available for renaming, MCA can predict +dispatch stalls caused by the lack of registers. + +The number of reorder buffer entries consumed by an instruction depends on the +number of micro-opcodes specified by the target scheduling model. MCA's +reorder buffer's purpose is to track the progress of instructions that are +"in-flight," and to retire instructions in program order. The number of +entries in the reorder buffer defaults to the `MicroOpBufferSize` provided by +the target scheduling model. + +Instructions that are dispatched to the schedulers consume scheduler buffer +entries. :program:`llvm-mca` queries the scheduling model to determine the set +of buffered resources consumed by an instruction. Buffered resources are +treated like scheduler resources. + +Instruction Issue +""""""""""""""""" +Each processor scheduler implements a buffer of instructions. An instruction +has to wait in the scheduler's buffer until input register operands become +available. Only at that point, does the instruction becomes eligible for +execution and may be issued (potentially out-of-order) for execution. +Instruction latencies are computed by :program:`llvm-mca` with the help of the +scheduling model. + +:program:`llvm-mca`'s scheduler is designed to simulate multiple processor +schedulers. The scheduler is responsible for tracking data dependencies, and +dynamically selecting which processor resources are consumed by instructions. +It delegates the management of processor resource units and resource groups to a +resource manager. The resource manager is responsible for selecting resource +units that are consumed by instructions. For example, if an instruction +consumes 1cy of a resource group, the resource manager selects one of the +available units from the group; by default, the resource manager uses a +round-robin selector to guarantee that resource usage is uniformly distributed +between all units of a group. + +:program:`llvm-mca`'s scheduler implements three instruction queues: + +* WaitQueue: a queue of instructions whose operands are not ready. +* ReadyQueue: a queue of instructions ready to execute. +* IssuedQueue: a queue of instructions executing. + +Depending on the operand availability, instructions that are dispatched to the +scheduler are either placed into the WaitQueue or into the ReadyQueue. + +Every cycle, the scheduler checks if instructions can be moved from the +WaitQueue to the ReadyQueue, and if instructions from the ReadyQueue can be +issued to the underlying pipelines. The algorithm prioritizes older instructions +over younger instructions. + +Write-Back and Retire Stage +""""""""""""""""""""""""""" +Issued instructions are moved from the ReadyQueue to the IssuedQueue. There, +instructions wait until they reach the write-back stage. At that point, they +get removed from the queue and the retire control unit is notified. + +When instructions are executed, the retire control unit flags the +instruction as "ready to retire." + +Instructions are retired in program order. The register file is notified of +the retirement so that it can free the physical registers that were allocated +for the instruction during the register renaming stage. + +Load/Store Unit and Memory Consistency Model +"""""""""""""""""""""""""""""""""""""""""""" +To simulate an out-of-order execution of memory operations, :program:`llvm-mca` +utilizes a simulated load/store unit (LSUnit) to simulate the speculative +execution of loads and stores. + +Each load (or store) consumes an entry in the load (or store) queue. Users can +specify flags ``-lqueue`` and ``-squeue`` to limit the number of entries in the +load and store queues respectively. The queues are unbounded by default. + +The LSUnit implements a relaxed consistency model for memory loads and stores. +The rules are: + +1. A younger load is allowed to pass an older load only if there are no + intervening stores or barriers between the two loads. +2. A younger load is allowed to pass an older store provided that the load does + not alias with the store. +3. A younger store is not allowed to pass an older store. +4. A younger store is not allowed to pass an older load. + +By default, the LSUnit optimistically assumes that loads do not alias +(`-noalias=true`) store operations. Under this assumption, younger loads are +always allowed to pass older stores. Essentially, the LSUnit does not attempt +to run any alias analysis to predict when loads and stores do not alias with +each other. + +Note that, in the case of write-combining memory, rule 3 could be relaxed to +allow reordering of non-aliasing store operations. That being said, at the +moment, there is no way to further relax the memory model (``-noalias`` is the +only option). Essentially, there is no option to specify a different memory +type (e.g., write-back, write-combining, write-through; etc.) and consequently +to weaken, or strengthen, the memory model. + +Other limitations are: + +* The LSUnit does not know when store-to-load forwarding may occur. +* The LSUnit does not know anything about cache hierarchy and memory types. +* The LSUnit does not know how to identify serializing operations and memory + fences. + +The LSUnit does not attempt to predict if a load or store hits or misses the L1 +cache. It only knows if an instruction "MayLoad" and/or "MayStore." For +loads, the scheduling model provides an "optimistic" load-to-use latency (which +usually matches the load-to-use latency for when there is a hit in the L1D). + +:program:`llvm-mca` does not know about serializing operations or memory-barrier +like instructions. The LSUnit conservatively assumes that an instruction which +has both "MayLoad" and unmodeled side effects behaves like a "soft" +load-barrier. That means, it serializes loads without forcing a flush of the +load queue. Similarly, instructions that "MayStore" and have unmodeled side +effects are treated like store barriers. A full memory barrier is a "MayLoad" +and "MayStore" instruction with unmodeled side effects. This is inaccurate, but +it is the best that we can do at the moment with the current information +available in LLVM. + +A load/store barrier consumes one entry of the load/store queue. A load/store +barrier enforces ordering of loads/stores. A younger load cannot pass a load +barrier. Also, a younger store cannot pass a store barrier. A younger load +has to wait for the memory/load barrier to execute. A load/store barrier is +"executed" when it becomes the oldest entry in the load/store queue(s). That +also means, by construction, all of the older loads/stores have been executed. + +In conclusion, the full set of load/store consistency rules are: + +#. A store may not pass a previous store. +#. A store may not pass a previous load (regardless of ``-noalias``). +#. A store has to wait until an older store barrier is fully executed. +#. A load may pass a previous load. +#. A load may not pass a previous store unless ``-noalias`` is set. +#. A load has to wait until an older load barrier is fully executed. |