2 .\" Man page generated from reStructuredText.
5 .nr rst2man-indent-level 0
9 level \\n[rst2man-indent-level]
10 level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
17 .\" .rstReportMargin pre:
19 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
20 . nr rst2man-indent-level +1
21 .\" .rstReportMargin post:
25 .\" indent \\n[an-margin]
26 .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
27 .nr rst2man-indent-level -1
28 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
29 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
31 .TH "LLVM-MCA" "1" "2021-06-07" "12" "LLVM"
33 llvm-mca \- LLVM Machine Code Analyzer
36 \fBllvm\-mca\fP [\fIoptions\fP] [input]
39 \fBllvm\-mca\fP is a performance analysis tool that uses information
40 available in LLVM (e.g. scheduling models) to statically measure the performance
41 of machine code in a specific CPU.
43 Performance is measured in terms of throughput as well as processor resource
44 consumption. The tool currently works for processors with an out\-of\-order
45 backend, for which there is a scheduling model available in LLVM.
47 The main goal of this tool is not just to predict the performance of the code
48 when run on the target, but also help with diagnosing potential performance
51 Given an assembly code sequence, \fBllvm\-mca\fP estimates the Instructions
52 Per Cycle (IPC), as well as hardware resource pressure. The analysis and
53 reporting style were inspired by the IACA tool from Intel.
55 For example, you can compile code with clang, output assembly, and pipe it
56 directly into \fBllvm\-mca\fP for analysis:
62 $ clang foo.c \-O2 \-target x86_64\-unknown\-unknown \-S \-o \- | llvm\-mca \-mcpu=btver2
74 $ clang foo.c \-O2 \-target x86_64\-unknown\-unknown \-mllvm \-x86\-asm\-syntax=intel \-S \-o \- | llvm\-mca \-mcpu=btver2
80 (\fBllvm\-mca\fP detects Intel syntax by the presence of an \fI\&.intel_syntax\fP
81 directive at the beginning of the input. By default its output syntax matches
84 Scheduling models are not just used to compute instruction latencies and
85 throughput, but also to understand what processor resources are available
86 and how to simulate them.
88 By design, the quality of the analysis conducted by \fBllvm\-mca\fP is
89 inevitably affected by the quality of the scheduling models in LLVM.
91 If you see that the performance report is not accurate for a processor,
92 please \fI\%file a bug\fP
93 against the appropriate backend.
96 If \fBinput\fP is "\fB\-\fP" or omitted, \fBllvm\-mca\fP reads from standard
97 input. Otherwise, it will read from the specified filename.
99 If the \fI\%\-o\fP option is omitted, then \fBllvm\-mca\fP will send its output
100 to standard output if the input is from standard input. If the \fI\%\-o\fP
101 option specifies "\fB\-\fP", then the output will also be sent to standard output.
105 Print a summary of command line options.
110 Use \fB<filename>\fP as the output filename. See the summary above for more
115 .B \-mtriple=<target triple>
116 Specify a target triple string.
121 Specify the architecture for which to analyze the code. It defaults to the
127 Specify the processor for which to analyze the code. By default, the cpu name
128 is autodetected from the host.
132 .B \-output\-asm\-variant=<variant id>
133 Specify the output assembly variant for the report generated by the tool.
134 On x86, possible values are [0, 1]. A value of 0 (vic. 1) for this flag enables
135 the AT&T (vic. Intel) assembly format for the code printed out by the tool in
141 Prefer hex format for numeric literals in the output assembly printed as part
146 .B \-dispatch=<width>
147 Specify a different dispatch width for the processor. The dispatch width
148 defaults to field \(aqIssueWidth\(aq in the processor scheduling model. If width is
149 zero, then the default dispatch width is used.
153 .B \-register\-file\-size=<size>
154 Specify the size of the register file. When specified, this flag limits how
155 many physical registers are available for register renaming purposes. A value
156 of zero for this flag means "unlimited number of physical registers".
160 .B \-iterations=<number of iterations>
161 Specify the number of iterations to run. If this flag is set to 0, then the
162 tool sets the number of iterations to a default value (i.e. 100).
167 If set, the tool assumes that loads and stores don\(aqt alias. This is the
172 .B \-lqueue=<load queue size>
173 Specify the size of the load queue in the load/store unit emulated by the tool.
174 By default, the tool assumes an unbound number of entries in the load queue.
175 A value of zero for this flag is ignored, and the default load queue size is
180 .B \-squeue=<store queue size>
181 Specify the size of the store queue in the load/store unit emulated by the
182 tool. By default, the tool assumes an unbound number of entries in the store
183 queue. A value of zero for this flag is ignored, and the default store queue
184 size is used instead.
189 Enable the timeline view.
193 .B \-timeline\-max\-iterations=<iterations>
194 Limit the number of iterations to print in the timeline view. By default, the
195 timeline view prints information for up to 10 iterations.
199 .B \-timeline\-max\-cycles=<cycles>
200 Limit the number of cycles in the timeline view. By default, the number of
205 .B \-resource\-pressure
206 Enable the resource pressure view. This is enabled by default.
210 .B \-register\-file\-stats
211 Enable register file usage statistics.
216 Enable extra dispatch statistics. This view collects and analyzes instruction
217 dispatch events, as well as static/dynamic dispatch stall events. This view
218 is disabled by default.
222 .B \-scheduler\-stats
223 Enable extra scheduler statistics. This view collects and analyzes instruction
224 issue events. This view is disabled by default.
229 Enable extra retire control unit statistics. This view is disabled by default.
233 .B \-instruction\-info
234 Enable the instruction info view. This is enabled by default.
239 Enable the printing of instruction encodings within the instruction info view.
244 Print all hardware statistics. This enables extra statistics related to the
245 dispatch logic, the hardware schedulers, the register file(s), and the retire
246 control unit. This option is disabled by default.
255 .B \-instruction\-tables
256 Prints resource pressure information based on the static information
257 available from the processor model. This differs from the resource pressure
258 view because it doesn\(aqt require that the code is simulated. It instead prints
259 the theoretical uniform distribution of resource pressure for every
260 instruction in sequence.
264 .B \-bottleneck\-analysis
265 Print information about bottlenecks that affect the throughput. This analysis
266 can be expensive, and it is disabled by default. Bottlenecks are highlighted
272 Print the requested views in JSON format. The instructions and the processor
273 resources are printed as members of special top level JSON objects. The
274 individual views refer to them by index.
278 \fBllvm\-mca\fP returns 0 on success. Otherwise, an error message is printed
279 to standard error, and the tool returns 1.
280 .SH USING MARKERS TO ANALYZE SPECIFIC CODE BLOCKS
282 \fBllvm\-mca\fP allows for the optional usage of special code comments to
283 mark regions of the assembly code to be analyzed. A comment starting with
284 substring \fBLLVM\-MCA\-BEGIN\fP marks the beginning of a code region. A comment
285 starting with substring \fBLLVM\-MCA\-END\fP marks the end of a code region. For
300 If no user\-defined region is specified, then \fBllvm\-mca\fP assumes a
301 default region which contains every instruction in the input file. Every region
302 is analyzed in isolation, and the final performance report is the union of all
303 the reports generated for every code region.
305 Code regions can have names. For example:
311 # LLVM\-MCA\-BEGIN A simple example
319 The code from the example above defines a region named "A simple example" with a
320 single instruction in it. Note how the region name doesn\(aqt have to be repeated
321 in the \fBLLVM\-MCA\-END\fP directive. In the absence of overlapping regions,
322 an anonymous \fBLLVM\-MCA\-END\fP directive always ends the currently active user
325 Example of nesting regions:
331 # LLVM\-MCA\-BEGIN foo
333 # LLVM\-MCA\-BEGIN bar
342 Example of overlapping regions:
348 # LLVM\-MCA\-BEGIN foo
350 # LLVM\-MCA\-BEGIN bar
360 Note that multiple anonymous regions cannot overlap. Also, overlapping regions
361 cannot have the same name.
363 There is no support for marking regions from high\-level source code, like C or
364 C++. As a workaround, inline assembly directives may be used:
370 int foo(int a, int b) {
371 __asm volatile("# LLVM\-MCA\-BEGIN foo");
373 __asm volatile("# LLVM\-MCA\-END");
382 However, this interferes with optimizations like loop vectorization and may have
383 an impact on the code generated. This is because the \fB__asm\fP statements are
384 seen as real code having important side effects, which limits how the code
385 around them can be transformed. If users want to make use of inline assembly
386 to emit markers, then the recommendation is to always verify that the output
387 assembly is equivalent to the assembly generated in the absence of markers.
388 The \fI\%Clang options to emit optimization reports\fP
389 can also help in detecting missed optimizations.
390 .SH HOW LLVM-MCA WORKS
392 \fBllvm\-mca\fP takes assembly code as input. The assembly code is parsed
393 into a sequence of MCInst with the help of the existing LLVM target assembly
394 parsers. The parsed sequence of MCInst is then analyzed by a \fBPipeline\fP module
395 to generate a performance report.
397 The Pipeline module simulates the execution of the machine code sequence in a
398 loop of iterations (default is 100). During this process, the pipeline collects
399 a number of execution related statistics. At the end of this process, the
400 pipeline generates and prints a report from the collected statistics.
402 Here is an example of a performance report generated by the tool for a
403 dot\-product of two packed float vectors of four elements. The analysis is
404 conducted for target x86, cpu btver2. The following result can be produced via
405 the following command using the example located at
406 \fBtest/tools/llvm\-mca/X86/BtVer2/dot\-product.s\fP:
412 $ llvm\-mca \-mtriple=x86_64\-unknown\-unknown \-mcpu=btver2 \-iterations=300 dot\-product.s
430 Block RThroughput: 2.0
439 [6]: HasSideEffects (U)
441 [1] [2] [3] [4] [5] [6] Instructions:
442 1 2 1.00 vmulps %xmm0, %xmm1, %xmm2
443 1 3 1.00 vhaddps %xmm2, %xmm2, %xmm3
444 1 3 1.00 vhaddps %xmm3, %xmm3, %xmm4
464 Resource pressure per iteration:
465 [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]
466 \- \- \- 2.00 1.00 2.00 1.00 \- \- \- \- \- \- \-
468 Resource pressure by instruction:
469 [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] Instructions:
470 \- \- \- \- 1.00 \- 1.00 \- \- \- \- \- \- \- vmulps %xmm0, %xmm1, %xmm2
471 \- \- \- 1.00 \- 1.00 \- \- \- \- \- \- \- \- vhaddps %xmm2, %xmm2, %xmm3
472 \- \- \- 1.00 \- 1.00 \- \- \- \- \- \- \- \- vhaddps %xmm3, %xmm3, %xmm4
478 According to this report, the dot\-product kernel has been executed 300 times,
479 for a total of 900 simulated instructions. The total number of simulated micro
480 opcodes (uOps) is also 900.
482 The report is structured in three main sections. The first section collects a
483 few performance numbers; the goal of this section is to give a very quick
484 overview of the performance throughput. Important performance indicators are
485 \fBIPC\fP, \fBuOps Per Cycle\fP, and \fBBlock RThroughput\fP (Block Reciprocal
488 Field \fIDispatchWidth\fP is the maximum number of micro opcodes that are dispatched
489 to the out\-of\-order backend every simulated cycle.
491 IPC is computed dividing the total number of simulated instructions by the total
494 Field \fIBlock RThroughput\fP is the reciprocal of the block throughput. Block
495 throughput is a theoretical quantity computed as the maximum number of blocks
496 (i.e. iterations) that can be executed per simulated clock cycle in the absence
497 of loop carried dependencies. Block throughput is superiorly limited by the
498 dispatch rate, and the availability of hardware resources.
500 In the absence of loop\-carried data dependencies, the observed IPC tends to a
501 theoretical maximum which can be computed by dividing the number of instructions
502 of a single iteration by the \fIBlock RThroughput\fP\&.
504 Field \(aquOps Per Cycle\(aq is computed dividing the total number of simulated micro
505 opcodes by the total number of cycles. A delta between Dispatch Width and this
506 field is an indicator of a performance issue. In the absence of loop\-carried
507 data dependencies, the observed \(aquOps Per Cycle\(aq should tend to a theoretical
508 maximum throughput which can be computed by dividing the number of uOps of a
509 single iteration by the \fIBlock RThroughput\fP\&.
511 Field \fIuOps Per Cycle\fP is bounded from above by the dispatch width. That is
512 because the dispatch width limits the maximum size of a dispatch group. Both IPC
513 and \(aquOps Per Cycle\(aq are limited by the amount of hardware parallelism. The
514 availability of hardware resources affects the resource pressure distribution,
515 and it limits the number of instructions that can be executed in parallel every
516 cycle. A delta between Dispatch Width and the theoretical maximum uOps per
517 Cycle (computed by dividing the number of uOps of a single iteration by the
518 \fIBlock RThroughput\fP) is an indicator of a performance bottleneck caused by the
519 lack of hardware resources.
520 In general, the lower the Block RThroughput, the better.
522 In this example, \fBuOps per iteration/Block RThroughput\fP is 1.50. Since there
523 are no loop\-carried dependencies, the observed \fIuOps Per Cycle\fP is expected to
524 approach 1.50 when the number of iterations tends to infinity. The delta between
525 the Dispatch Width (2.00), and the theoretical maximum uOp throughput (1.50) is
526 an indicator of a performance bottleneck caused by the lack of hardware
527 resources, and the \fIResource pressure view\fP can help to identify the problematic
530 The second section of the report is the \fIinstruction info view\fP\&. It shows the
531 latency and reciprocal throughput of every instruction in the sequence. It also
532 reports extra information related to the number of micro opcodes, and opcode
533 properties (i.e., \(aqMayLoad\(aq, \(aqMayStore\(aq, and \(aqHasSideEffects\(aq).
535 Field \fIRThroughput\fP is the reciprocal of the instruction throughput. Throughput
536 is computed as the maximum number of instructions of a same type that can be
537 executed per clock cycle in the absence of operand dependencies. In this
538 example, the reciprocal throughput of a vector float multiply is 1
539 cycles/instruction. That is because the FP multiplier JFPM is only available
542 Instruction encodings are displayed within the instruction info view when flag
543 \fI\-show\-encoding\fP is specified.
545 Below is an example of \fI\-show\-encoding\fP output for the dot\-product kernel:
557 [6]: HasSideEffects (U)
560 [1] [2] [3] [4] [5] [6] [7] Encodings: Instructions:
561 1 2 1.00 4 c5 f0 59 d0 vmulps %xmm0, %xmm1, %xmm2
562 1 4 1.00 4 c5 eb 7c da vhaddps %xmm2, %xmm2, %xmm3
563 1 4 1.00 4 c5 e3 7c e3 vhaddps %xmm3, %xmm3, %xmm4
569 The \fIEncoding Size\fP column shows the size in bytes of instructions. The
570 \fIEncodings\fP column shows the actual instruction encodings (byte sequences in
573 The third section is the \fIResource pressure view\fP\&. This view reports
574 the average number of resource cycles consumed every iteration by instructions
575 for every processor resource unit available on the target. Information is
576 structured in two tables. The first table reports the number of resource cycles
577 spent on average every iteration. The second table correlates the resource
578 cycles to the machine instruction in the sequence. For example, every iteration
579 of the instruction vmulps always executes on resource unit [6]
580 (JFPU1 \- floating point pipeline #1), consuming an average of 1 resource cycle
581 per iteration. Note that on AMD Jaguar, vector floating\-point multiply can
582 only be issued to pipeline JFPU1, while horizontal floating\-point additions can
583 only be issued to pipeline JFPU0.
585 The resource pressure view helps with identifying bottlenecks caused by high
586 usage of specific hardware resources. Situations with resource pressure mainly
587 concentrated on a few resources should, in general, be avoided. Ideally,
588 pressure should be uniformly distributed between multiple resources.
591 The timeline view produces a detailed report of each instruction\(aqs state
592 transitions through an instruction pipeline. This view is enabled by the
593 command line option \fB\-timeline\fP\&. As instructions transition through the
594 various stages of the pipeline, their states are depicted in the view report.
595 These states are represented by the following characters:
598 D : Instruction dispatched.
600 e : Instruction executing.
602 E : Instruction executed.
604 R : Instruction retired.
606 = : Instruction already dispatched, waiting to be executed.
608 \- : Instruction executed, waiting to be retired.
611 Below is the timeline view for a subset of the dot\-product example located in
612 \fBtest/tools/llvm\-mca/X86/BtVer2/dot\-product.s\fP and processed by
613 \fBllvm\-mca\fP using the following command:
619 $ llvm\-mca \-mtriple=x86_64\-unknown\-unknown \-mcpu=btver2 \-iterations=3 \-timeline dot\-product.s
633 [0,0] DeeER. . . vmulps %xmm0, %xmm1, %xmm2
634 [0,1] D==eeeER . . vhaddps %xmm2, %xmm2, %xmm3
635 [0,2] .D====eeeER . vhaddps %xmm3, %xmm3, %xmm4
636 [1,0] .DeeE\-\-\-\-\-R . vmulps %xmm0, %xmm1, %xmm2
637 [1,1] . D=eeeE\-\-\-R . vhaddps %xmm2, %xmm2, %xmm3
638 [1,2] . D====eeeER . vhaddps %xmm3, %xmm3, %xmm4
639 [2,0] . DeeE\-\-\-\-\-R . vmulps %xmm0, %xmm1, %xmm2
640 [2,1] . D====eeeER . vhaddps %xmm2, %xmm2, %xmm3
641 [2,2] . D======eeeER vhaddps %xmm3, %xmm3, %xmm4
644 Average Wait times (based on the timeline view):
646 [1]: Average time spent waiting in a scheduler\(aqs queue
647 [2]: Average time spent waiting in a scheduler\(aqs queue while ready
648 [3]: Average time elapsed from WB until retire stage
651 0. 3 1.0 1.0 3.3 vmulps %xmm0, %xmm1, %xmm2
652 1. 3 3.3 0.7 1.0 vhaddps %xmm2, %xmm2, %xmm3
653 2. 3 5.7 0.0 0.0 vhaddps %xmm3, %xmm3, %xmm4
654 3 3.3 0.5 1.4 <total>
660 The timeline view is interesting because it shows instruction state changes
661 during execution. It also gives an idea of how the tool processes instructions
662 executed on the target, and how their timing information might be calculated.
664 The timeline view is structured in two tables. The first table shows
665 instructions changing state over time (measured in cycles); the second table
666 (named \fIAverage Wait times\fP) reports useful timing statistics, which should
667 help diagnose performance bottlenecks caused by long data dependencies and
668 sub\-optimal usage of hardware resources.
670 An instruction in the timeline view is identified by a pair of indices, where
671 the first index identifies an iteration, and the second index is the
672 instruction index (i.e., where it appears in the code sequence). Since this
673 example was generated using 3 iterations: \fB\-iterations=3\fP, the iteration
674 indices range from 0\-2 inclusively.
676 Excluding the first and last column, the remaining columns are in cycles.
677 Cycles are numbered sequentially starting from 0.
679 From the example output above, we know the following:
682 Instruction [1,0] was dispatched at cycle 1.
684 Instruction [1,0] started executing at cycle 2.
686 Instruction [1,0] reached the write back stage at cycle 4.
688 Instruction [1,0] was retired at cycle 10.
691 Instruction [1,0] (i.e., vmulps from iteration #1) does not have to wait in the
692 scheduler\(aqs queue for the operands to become available. By the time vmulps is
693 dispatched, operands are already available, and pipeline JFPU1 is ready to
694 serve another instruction. So the instruction can be immediately issued on the
695 JFPU1 pipeline. That is demonstrated by the fact that the instruction only
696 spent 1cy in the scheduler\(aqs queue.
698 There is a gap of 5 cycles between the write\-back stage and the retire event.
699 That is because instructions must retire in program order, so [1,0] has to wait
700 for [0,2] to be retired first (i.e., it has to wait until cycle 10).
702 In the example, all instructions are in a RAW (Read After Write) dependency
703 chain. Register %xmm2 written by vmulps is immediately used by the first
704 vhaddps, and register %xmm3 written by the first vhaddps is used by the second
705 vhaddps. Long data dependencies negatively impact the ILP (Instruction Level
708 In the dot\-product example, there are anti\-dependencies introduced by
709 instructions from different iterations. However, those dependencies can be
710 removed at register renaming stage (at the cost of allocating register aliases,
711 and therefore consuming physical registers).
713 Table \fIAverage Wait times\fP helps diagnose performance issues that are caused by
714 the presence of long latency instructions and potentially long data dependencies
715 which may limit the ILP. Last row, \fB<total>\fP, shows a global average over all
716 instructions measured. Note that \fBllvm\-mca\fP, by default, assumes at
717 least 1cy between the dispatch event and the issue event.
719 When the performance is limited by data dependencies and/or long latency
720 instructions, the number of cycles spent while in the \fIready\fP state is expected
721 to be very small when compared with the total number of cycles spent in the
722 scheduler\(aqs queue. The difference between the two counters is a good indicator
723 of how large of an impact data dependencies had on the execution of the
724 instructions. When performance is mostly limited by the lack of hardware
725 resources, the delta between the two counters is small. However, the number of
726 cycles spent in the queue tends to be larger (i.e., more than 1\-3cy),
727 especially when compared to other low latency instructions.
728 .SS Bottleneck Analysis
730 The \fB\-bottleneck\-analysis\fP command line option enables the analysis of
731 performance bottlenecks.
733 This analysis is potentially expensive. It attempts to correlate increases in
734 backend pressure (caused by pipeline resource pressure and data dependencies) to
735 dynamic dispatch stalls.
737 Below is an example of \fB\-bottleneck\-analysis\fP output generated by
738 \fBllvm\-mca\fP for 500 iterations of the dot\-product example on btver2.
744 Cycles with backend pressure increase [ 48.07% ]
745 Throughput Bottlenecks:
746 Resource Pressure [ 47.77% ]
749 Data Dependencies: [ 0.30% ]
750 \- Register Dependencies [ 0.30% ]
751 \- Memory Dependencies [ 0.00% ]
753 Critical sequence based on the simulation:
755 Instruction Dependency Information
756 +\-\-\-\-< 2. vhaddps %xmm3, %xmm3, %xmm4
760 | 0. vmulps %xmm0, %xmm1, %xmm2
761 +\-\-\-\-> 1. vhaddps %xmm2, %xmm2, %xmm3 ## RESOURCE interference: JFPA [ probability: 74% ]
762 +\-\-\-\-> 2. vhaddps %xmm3, %xmm3, %xmm4 ## REGISTER dependency: %xmm3
766 +\-\-\-\-> 1. vhaddps %xmm2, %xmm2, %xmm3 ## RESOURCE interference: JFPA [ probability: 74% ]
772 According to the analysis, throughput is limited by resource pressure and not by
773 data dependencies. The analysis observed increases in backend pressure during
774 48.07% of the simulated run. Almost all those pressure increase events were
775 caused by contention on processor resources JFPA/JFPU0.
777 The \fIcritical sequence\fP is the most expensive sequence of instructions according
778 to the simulation. It is annotated to provide extra information about critical
779 register dependencies and resource interferences between instructions.
781 Instructions from the critical sequence are expected to significantly impact
782 performance. By construction, the accuracy of this analysis is strongly
783 dependent on the simulation and (as always) by the quality of the processor
785 .SS Extra Statistics to Further Diagnose Performance Issues
787 The \fB\-all\-stats\fP command line option enables extra statistics and performance
788 counters for the dispatch logic, the reorder buffer, the retire control unit,
789 and the register file.
791 Below is an example of \fB\-all\-stats\fP output generated by \fBllvm\-mca\fP
792 for 300 iterations of the dot\-product example discussed in the previous
799 Dynamic Dispatch Stall Cycles:
800 RAT \- Register unavailable: 0
801 RCU \- Retire tokens unavailable: 0
802 SCHEDQ \- Scheduler full: 272 (44.6%)
803 LQ \- Load queue full: 0
804 SQ \- Store queue full: 0
805 GROUP \- Static restrictions on the dispatch group: 0
808 Dispatch Logic \- number of cycles where we saw N micro opcodes dispatched:
809 [# dispatched], [# cycles]
815 Schedulers \- number of cycles where we saw N micro opcodes issued:
816 [# issued], [# cycles]
821 Scheduler\(aqs queue usage:
823 [2] Average number of used buffer entries.
824 [3] Maximum number of used buffer entries.
825 [4] Total number of buffer entries.
833 Retire Control Unit \- number of cycles where we saw N instructions retired:
834 [# retired], [# cycles]
839 Total ROB Entries: 64
840 Max Used ROB Entries: 35 ( 54.7% )
841 Average Used ROB Entries per cy: 32 ( 50.0% )
844 Register File statistics:
845 Total number of mappings created: 900
846 Max number of mappings used: 35
848 * Register File #1 \-\- JFpuPRF:
849 Number of physical registers: 72
850 Total number of mappings created: 900
851 Max number of mappings used: 35
853 * Register File #2 \-\- JIntegerPRF:
854 Number of physical registers: 64
855 Total number of mappings created: 0
856 Max number of mappings used: 0
862 If we look at the \fIDynamic Dispatch Stall Cycles\fP table, we see the counter for
863 SCHEDQ reports 272 cycles. This counter is incremented every time the dispatch
864 logic is unable to dispatch a full group because the scheduler\(aqs queue is full.
866 Looking at the \fIDispatch Logic\fP table, we see that the pipeline was only able to
867 dispatch two micro opcodes 51.5% of the time. The dispatch group was limited to
868 one micro opcode 44.6% of the cycles, which corresponds to 272 cycles. The
869 dispatch statistics are displayed by either using the command option
870 \fB\-all\-stats\fP or \fB\-dispatch\-stats\fP\&.
872 The next table, \fISchedulers\fP, presents a histogram displaying a count,
873 representing the number of micro opcodes issued on some number of cycles. In
874 this case, of the 610 simulated cycles, single opcodes were issued 306 times
875 (50.2%) and there were 7 cycles where no opcodes were issued.
877 The \fIScheduler\(aqs queue usage\fP table shows that the average and maximum number of
878 buffer entries (i.e., scheduler queue entries) used at runtime. Resource JFPU01
879 reached its maximum (18 of 18 queue entries). Note that AMD Jaguar implements
883 JALU01 \- A scheduler for ALU instructions.
885 JFPU01 \- A scheduler floating point operations.
887 JLSAGU \- A scheduler for address generation.
890 The dot\-product is a kernel of three floating point instructions (a vector
891 multiply followed by two horizontal adds). That explains why only the floating
892 point scheduler appears to be used.
894 A full scheduler queue is either caused by data dependency chains or by a
895 sub\-optimal usage of hardware resources. Sometimes, resource pressure can be
896 mitigated by rewriting the kernel using different instructions that consume
897 different scheduler resources. Schedulers with a small queue are less resilient
898 to bottlenecks caused by the presence of long data dependencies. The scheduler
899 statistics are displayed by using the command option \fB\-all\-stats\fP or
900 \fB\-scheduler\-stats\fP\&.
902 The next table, \fIRetire Control Unit\fP, presents a histogram displaying a count,
903 representing the number of instructions retired on some number of cycles. In
904 this case, of the 610 simulated cycles, two instructions were retired during the
905 same cycle 399 times (65.4%) and there were 109 cycles where no instructions
906 were retired. The retire statistics are displayed by using the command option
907 \fB\-all\-stats\fP or \fB\-retire\-stats\fP\&.
909 The last table presented is \fIRegister File statistics\fP\&. Each physical register
910 file (PRF) used by the pipeline is presented in this table. In the case of AMD
911 Jaguar, there are two register files, one for floating\-point registers (JFpuPRF)
912 and one for integer registers (JIntegerPRF). The table shows that of the 900
913 instructions processed, there were 900 mappings created. Since this dot\-product
914 example utilized only floating point registers, the JFPuPRF was responsible for
915 creating the 900 mappings. However, we see that the pipeline only used a
916 maximum of 35 of 72 available register slots at any given time. We can conclude
917 that the floating point PRF was the only register file used for the example, and
918 that it was never resource constrained. The register file statistics are
919 displayed by using the command option \fB\-all\-stats\fP or
920 \fB\-register\-file\-stats\fP\&.
922 In this example, we can conclude that the IPC is mostly limited by data
923 dependencies, and not by resource pressure.
926 This section describes the instruction flow through the default pipeline of
927 \fBllvm\-mca\fP, as well as the functional units involved in the process.
929 The default pipeline implements the following sequence of stages used to
930 process instructions.
933 Dispatch (Instruction is dispatched to the schedulers).
935 Issue (Instruction is issued to the processor pipelines).
937 Write Back (Instruction is executed, and results are written back).
939 Retire (Instruction is retired; writes are architecturally committed).
942 The default pipeline only models the out\-of\-order portion of a processor.
943 Therefore, the instruction fetch and decode stages are not modeled. Performance
944 bottlenecks in the frontend are not diagnosed. \fBllvm\-mca\fP assumes that
945 instructions have all been decoded and placed into a queue before the simulation
946 start. Also, \fBllvm\-mca\fP does not model branch prediction.
947 .SS Instruction Dispatch
949 During the dispatch stage, instructions are picked in program order from a
950 queue of already decoded instructions, and dispatched in groups to the
951 simulated hardware schedulers.
953 The size of a dispatch group depends on the availability of the simulated
954 hardware resources. The processor dispatch width defaults to the value
955 of the \fBIssueWidth\fP in LLVM\(aqs scheduling model.
957 An instruction can be dispatched if:
960 The size of the dispatch group is smaller than processor\(aqs dispatch width.
962 There are enough entries in the reorder buffer.
964 There are enough physical registers to do register renaming.
966 The schedulers are not full.
969 Scheduling models can optionally specify which register files are available on
970 the processor. \fBllvm\-mca\fP uses that information to initialize register
971 file descriptors. Users can limit the number of physical registers that are
972 globally available for register renaming by using the command option
973 \fB\-register\-file\-size\fP\&. A value of zero for this option means \fIunbounded\fP\&. By
974 knowing how many registers are available for renaming, the tool can predict
975 dispatch stalls caused by the lack of physical registers.
977 The number of reorder buffer entries consumed by an instruction depends on the
978 number of micro\-opcodes specified for that instruction by the target scheduling
979 model. The reorder buffer is responsible for tracking the progress of
980 instructions that are "in\-flight", and retiring them in program order. The
981 number of entries in the reorder buffer defaults to the value specified by field
982 \fIMicroOpBufferSize\fP in the target scheduling model.
984 Instructions that are dispatched to the schedulers consume scheduler buffer
985 entries. \fBllvm\-mca\fP queries the scheduling model to determine the set
986 of buffered resources consumed by an instruction. Buffered resources are
987 treated like scheduler resources.
988 .SS Instruction Issue
990 Each processor scheduler implements a buffer of instructions. An instruction
991 has to wait in the scheduler\(aqs buffer until input register operands become
992 available. Only at that point, does the instruction becomes eligible for
993 execution and may be issued (potentially out\-of\-order) for execution.
994 Instruction latencies are computed by \fBllvm\-mca\fP with the help of the
997 \fBllvm\-mca\fP\(aqs scheduler is designed to simulate multiple processor
998 schedulers. The scheduler is responsible for tracking data dependencies, and
999 dynamically selecting which processor resources are consumed by instructions.
1000 It delegates the management of processor resource units and resource groups to a
1001 resource manager. The resource manager is responsible for selecting resource
1002 units that are consumed by instructions. For example, if an instruction
1003 consumes 1cy of a resource group, the resource manager selects one of the
1004 available units from the group; by default, the resource manager uses a
1005 round\-robin selector to guarantee that resource usage is uniformly distributed
1006 between all units of a group.
1008 \fBllvm\-mca\fP\(aqs scheduler internally groups instructions into three sets:
1011 WaitSet: a set of instructions whose operands are not ready.
1013 ReadySet: a set of instructions ready to execute.
1015 IssuedSet: a set of instructions executing.
1018 Depending on the operands availability, instructions that are dispatched to the
1019 scheduler are either placed into the WaitSet or into the ReadySet.
1021 Every cycle, the scheduler checks if instructions can be moved from the WaitSet
1022 to the ReadySet, and if instructions from the ReadySet can be issued to the
1023 underlying pipelines. The algorithm prioritizes older instructions over younger
1025 .SS Write\-Back and Retire Stage
1027 Issued instructions are moved from the ReadySet to the IssuedSet. There,
1028 instructions wait until they reach the write\-back stage. At that point, they
1029 get removed from the queue and the retire control unit is notified.
1031 When instructions are executed, the retire control unit flags the instruction as
1034 Instructions are retired in program order. The register file is notified of the
1035 retirement so that it can free the physical registers that were allocated for
1036 the instruction during the register renaming stage.
1037 .SS Load/Store Unit and Memory Consistency Model
1039 To simulate an out\-of\-order execution of memory operations, \fBllvm\-mca\fP
1040 utilizes a simulated load/store unit (LSUnit) to simulate the speculative
1041 execution of loads and stores.
1043 Each load (or store) consumes an entry in the load (or store) queue. Users can
1044 specify flags \fB\-lqueue\fP and \fB\-squeue\fP to limit the number of entries in the
1045 load and store queues respectively. The queues are unbounded by default.
1047 The LSUnit implements a relaxed consistency model for memory loads and stores.
1051 A younger load is allowed to pass an older load only if there are no
1052 intervening stores or barriers between the two loads.
1054 A younger load is allowed to pass an older store provided that the load does
1055 not alias with the store.
1057 A younger store is not allowed to pass an older store.
1059 A younger store is not allowed to pass an older load.
1062 By default, the LSUnit optimistically assumes that loads do not alias
1063 (\fI\-noalias=true\fP) store operations. Under this assumption, younger loads are
1064 always allowed to pass older stores. Essentially, the LSUnit does not attempt
1065 to run any alias analysis to predict when loads and stores do not alias with
1068 Note that, in the case of write\-combining memory, rule 3 could be relaxed to
1069 allow reordering of non\-aliasing store operations. That being said, at the
1070 moment, there is no way to further relax the memory model (\fB\-noalias\fP is the
1071 only option). Essentially, there is no option to specify a different memory
1072 type (e.g., write\-back, write\-combining, write\-through; etc.) and consequently
1073 to weaken, or strengthen, the memory model.
1075 Other limitations are:
1078 The LSUnit does not know when store\-to\-load forwarding may occur.
1080 The LSUnit does not know anything about cache hierarchy and memory types.
1082 The LSUnit does not know how to identify serializing operations and memory
1086 The LSUnit does not attempt to predict if a load or store hits or misses the L1
1087 cache. It only knows if an instruction "MayLoad" and/or "MayStore." For
1088 loads, the scheduling model provides an "optimistic" load\-to\-use latency (which
1089 usually matches the load\-to\-use latency for when there is a hit in the L1D).
1091 \fBllvm\-mca\fP does not know about serializing operations or memory\-barrier
1092 like instructions. The LSUnit conservatively assumes that an instruction which
1093 has both "MayLoad" and unmodeled side effects behaves like a "soft"
1094 load\-barrier. That means, it serializes loads without forcing a flush of the
1095 load queue. Similarly, instructions that "MayStore" and have unmodeled side
1096 effects are treated like store barriers. A full memory barrier is a "MayLoad"
1097 and "MayStore" instruction with unmodeled side effects. This is inaccurate, but
1098 it is the best that we can do at the moment with the current information
1101 A load/store barrier consumes one entry of the load/store queue. A load/store
1102 barrier enforces ordering of loads/stores. A younger load cannot pass a load
1103 barrier. Also, a younger store cannot pass a store barrier. A younger load
1104 has to wait for the memory/load barrier to execute. A load/store barrier is
1105 "executed" when it becomes the oldest entry in the load/store queue(s). That
1106 also means, by construction, all of the older loads/stores have been executed.
1108 In conclusion, the full set of load/store consistency rules are:
1111 A store may not pass a previous store.
1113 A store may not pass a previous load (regardless of \fB\-noalias\fP).
1115 A store has to wait until an older store barrier is fully executed.
1117 A load may pass a previous load.
1119 A load may not pass a previous store unless \fB\-noalias\fP is set.
1121 A load has to wait until an older load barrier is fully executed.
1124 Maintained by the LLVM Team (https://llvm.org/).
1126 2003-2021, LLVM Project
1127 .\" Generated by docutils manpage writer.
projects / FreeBSD / FreeBSD.git / blob