2 .\" Man page generated from reStructuredText.
4 .TH "LLVM-MCA" "1" "2018-08-02" "7" "LLVM"
6 llvm-mca \- LLVM Machine Code Analyzer
8 .nr rst2man-indent-level 0
12 level \\n[rst2man-indent-level]
13 level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
20 .\" .rstReportMargin pre:
22 . nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
23 . nr rst2man-indent-level +1
24 .\" .rstReportMargin post:
28 .\" indent \\n[an-margin]
29 .\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
30 .nr rst2man-indent-level -1
31 .\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
32 .in \\n[rst2man-indent\\n[rst2man-indent-level]]u
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, llvm\-mca estimates the Instructions Per Cycle
52 (IPC), as well as hardware resource pressure. The analysis and reporting style
53 were inspired by the IACA tool from Intel.
55 \fBllvm\-mca\fP allows the usage of special code comments to mark regions of
56 the assembly code to be analyzed. A comment starting with substring
57 \fBLLVM\-MCA\-BEGIN\fP marks the beginning of a code region. A comment starting with
58 substring \fBLLVM\-MCA\-END\fP marks the end of a code region. For example:
64 # LLVM\-MCA\-BEGIN My Code Region
72 Multiple regions can be specified provided that they do not overlap. A code
73 region can have an optional description. If no user\-defined region is specified,
74 then \fBllvm\-mca\fP assumes a default region which contains every
75 instruction in the input file. Every region is analyzed in isolation, and the
76 final performance report is the union of all the reports generated for every
79 Inline assembly directives may be used from source code to annotate the
86 int foo(int a, int b) {
87 __asm volatile("# LLVM\-MCA\-BEGIN foo");
89 __asm volatile("# LLVM\-MCA\-END");
98 So for example, you can compile code with clang, output assembly, and pipe it
99 directly into llvm\-mca for analysis:
105 $ clang foo.c \-O2 \-target x86_64\-unknown\-unknown \-S \-o \- | llvm\-mca \-mcpu=btver2
117 $ clang foo.c \-O2 \-target x86_64\-unknown\-unknown \-mllvm \-x86\-asm\-syntax=intel \-S \-o \- | llvm\-mca \-mcpu=btver2
124 If \fBinput\fP is "\fB\-\fP" or omitted, \fBllvm\-mca\fP reads from standard
125 input. Otherwise, it will read from the specified filename.
127 If the \fB\-o\fP option is omitted, then \fBllvm\-mca\fP will send its output
128 to standard output if the input is from standard input. If the \fB\-o\fP
129 option specifies "\fB\-\fP", then the output will also be sent to standard output.
133 Print a summary of command line options.
137 .B \-mtriple=<target triple>
138 Specify a target triple string.
143 Specify the architecture for which to analyze the code. It defaults to the
149 Specify the processor for which to analyze the code. By default, the cpu name
150 is autodetected from the host.
154 .B \-output\-asm\-variant=<variant id>
155 Specify the output assembly variant for the report generated by the tool.
156 On x86, possible values are [0, 1]. A value of 0 (vic. 1) for this flag enables
157 the AT&T (vic. Intel) assembly format for the code printed out by the tool in
162 .B \-dispatch=<width>
163 Specify a different dispatch width for the processor. The dispatch width
164 defaults to field \(aqIssueWidth\(aq in the processor scheduling model. If width is
165 zero, then the default dispatch width is used.
169 .B \-register\-file\-size=<size>
170 Specify the size of the register file. When specified, this flag limits how
171 many physical registers are available for register renaming purposes. A value
172 of zero for this flag means "unlimited number of physical registers".
176 .B \-iterations=<number of iterations>
177 Specify the number of iterations to run. If this flag is set to 0, then the
178 tool sets the number of iterations to a default value (i.e. 100).
183 If set, the tool assumes that loads and stores don\(aqt alias. This is the
188 .B \-lqueue=<load queue size>
189 Specify the size of the load queue in the load/store unit emulated by the tool.
190 By default, the tool assumes an unbound number of entries in the load queue.
191 A value of zero for this flag is ignored, and the default load queue size is
196 .B \-squeue=<store queue size>
197 Specify the size of the store queue in the load/store unit emulated by the
198 tool. By default, the tool assumes an unbound number of entries in the store
199 queue. A value of zero for this flag is ignored, and the default store queue
200 size is used instead.
205 Enable the timeline view.
209 .B \-timeline\-max\-iterations=<iterations>
210 Limit the number of iterations to print in the timeline view. By default, the
211 timeline view prints information for up to 10 iterations.
215 .B \-timeline\-max\-cycles=<cycles>
216 Limit the number of cycles in the timeline view. By default, the number of
221 .B \-resource\-pressure
222 Enable the resource pressure view. This is enabled by default.
226 .B \-register\-file\-stats
227 Enable register file usage statistics.
232 Enable extra dispatch statistics. This view collects and analyzes instruction
233 dispatch events, as well as static/dynamic dispatch stall events. This view
234 is disabled by default.
238 .B \-scheduler\-stats
239 Enable extra scheduler statistics. This view collects and analyzes instruction
240 issue events. This view is disabled by default.
245 Enable extra retire control unit statistics. This view is disabled by default.
249 .B \-instruction\-info
250 Enable the instruction info view. This is enabled by default.
255 Print all hardware statistics. This enables extra statistics related to the
256 dispatch logic, the hardware schedulers, the register file(s), and the retire
257 control unit. This option is disabled by default.
266 .B \-instruction\-tables
267 Prints resource pressure information based on the static information
268 available from the processor model. This differs from the resource pressure
269 view because it doesn\(aqt require that the code is simulated. It instead prints
270 the theoretical uniform distribution of resource pressure for every
271 instruction in sequence.
275 \fBllvm\-mca\fP returns 0 on success. Otherwise, an error message is printed
276 to standard error, and the tool returns 1.
277 .SH HOW LLVM-MCA WORKS
279 \fBllvm\-mca\fP takes assembly code as input. The assembly code is parsed
280 into a sequence of MCInst with the help of the existing LLVM target assembly
281 parsers. The parsed sequence of MCInst is then analyzed by a \fBPipeline\fP module
282 to generate a performance report.
284 The Pipeline module simulates the execution of the machine code sequence in a
285 loop of iterations (default is 100). During this process, the pipeline collects
286 a number of execution related statistics. At the end of this process, the
287 pipeline generates and prints a report from the collected statistics.
289 Here is an example of a performance report generated by the tool for a
290 dot\-product of two packed float vectors of four elements. The analysis is
291 conducted for target x86, cpu btver2. The following result can be produced via
292 the following command using the example located at
293 \fBtest/tools/llvm\-mca/X86/BtVer2/dot\-product.s\fP:
299 $ llvm\-mca \-mtriple=x86_64\-unknown\-unknown \-mcpu=btver2 \-iterations=300 dot\-product.s
314 Block RThroughput: 2.0
323 [6]: HasSideEffects (U)
325 [1] [2] [3] [4] [5] [6] Instructions:
326 1 2 1.00 vmulps %xmm0, %xmm1, %xmm2
327 1 3 1.00 vhaddps %xmm2, %xmm2, %xmm3
328 1 3 1.00 vhaddps %xmm3, %xmm3, %xmm4
348 Resource pressure per iteration:
349 [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]
350 \- \- \- 2.00 1.00 2.00 1.00 \- \- \- \- \- \- \-
352 Resource pressure by instruction:
353 [0] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] Instructions:
354 \- \- \- \- 1.00 \- 1.00 \- \- \- \- \- \- \- vmulps %xmm0, %xmm1, %xmm2
355 \- \- \- 1.00 \- 1.00 \- \- \- \- \- \- \- \- vhaddps %xmm2, %xmm2, %xmm3
356 \- \- \- 1.00 \- 1.00 \- \- \- \- \- \- \- \- vhaddps %xmm3, %xmm3, %xmm4
362 According to this report, the dot\-product kernel has been executed 300 times,
363 for a total of 900 dynamically executed instructions.
365 The report is structured in three main sections. The first section collects a
366 few performance numbers; the goal of this section is to give a very quick
367 overview of the performance throughput. In this example, the two important
368 performance indicators are \fBIPC\fP and \fBBlock RThroughput\fP (Block Reciprocal
371 IPC is computed dividing the total number of simulated instructions by the total
372 number of cycles. A delta between Dispatch Width and IPC is an indicator of a
373 performance issue. In the absence of loop\-carried data dependencies, the
374 observed IPC tends to a theoretical maximum which can be computed by dividing
375 the number of instructions of a single iteration by the \fIBlock RThroughput\fP\&.
377 IPC is bounded from above by the dispatch width. That is because the dispatch
378 width limits the maximum size of a dispatch group. IPC is also limited by the
379 amount of hardware parallelism. The availability of hardware resources affects
380 the resource pressure distribution, and it limits the number of instructions
381 that can be executed in parallel every cycle. A delta between Dispatch
382 Width and the theoretical maximum IPC is an indicator of a performance
383 bottleneck caused by the lack of hardware resources. In general, the lower the
384 Block RThroughput, the better.
386 In this example, \fBInstructions per iteration/Block RThroughput\fP is 1.50. Since
387 there are no loop\-carried dependencies, the observed IPC is expected to approach
388 1.50 when the number of iterations tends to infinity. The delta between the
389 Dispatch Width (2.00), and the theoretical maximum IPC (1.50) is an indicator of
390 a performance bottleneck caused by the lack of hardware resources, and the
391 \fIResource pressure view\fP can help to identify the problematic resource usage.
393 The second section of the report shows the latency and reciprocal
394 throughput of every instruction in the sequence. That section also reports
395 extra information related to the number of micro opcodes, and opcode properties
396 (i.e., \(aqMayLoad\(aq, \(aqMayStore\(aq, and \(aqHasSideEffects\(aq).
398 The third section is the \fIResource pressure view\fP\&. This view reports
399 the average number of resource cycles consumed every iteration by instructions
400 for every processor resource unit available on the target. Information is
401 structured in two tables. The first table reports the number of resource cycles
402 spent on average every iteration. The second table correlates the resource
403 cycles to the machine instruction in the sequence. For example, every iteration
404 of the instruction vmulps always executes on resource unit [6]
405 (JFPU1 \- floating point pipeline #1), consuming an average of 1 resource cycle
406 per iteration. Note that on AMD Jaguar, vector floating\-point multiply can
407 only be issued to pipeline JFPU1, while horizontal floating\-point additions can
408 only be issued to pipeline JFPU0.
410 The resource pressure view helps with identifying bottlenecks caused by high
411 usage of specific hardware resources. Situations with resource pressure mainly
412 concentrated on a few resources should, in general, be avoided. Ideally,
413 pressure should be uniformly distributed between multiple resources.
416 The timeline view produces a detailed report of each instruction\(aqs state
417 transitions through an instruction pipeline. This view is enabled by the
418 command line option \fB\-timeline\fP\&. As instructions transition through the
419 various stages of the pipeline, their states are depicted in the view report.
420 These states are represented by the following characters:
423 D : Instruction dispatched.
425 e : Instruction executing.
427 E : Instruction executed.
429 R : Instruction retired.
431 = : Instruction already dispatched, waiting to be executed.
433 \- : Instruction executed, waiting to be retired.
436 Below is the timeline view for a subset of the dot\-product example located in
437 \fBtest/tools/llvm\-mca/X86/BtVer2/dot\-product.s\fP and processed by
438 \fBllvm\-mca\fP using the following command:
444 $ llvm\-mca \-mtriple=x86_64\-unknown\-unknown \-mcpu=btver2 \-iterations=3 \-timeline dot\-product.s
458 [0,0] DeeER. . . vmulps %xmm0, %xmm1, %xmm2
459 [0,1] D==eeeER . . vhaddps %xmm2, %xmm2, %xmm3
460 [0,2] .D====eeeER . vhaddps %xmm3, %xmm3, %xmm4
461 [1,0] .DeeE\-\-\-\-\-R . vmulps %xmm0, %xmm1, %xmm2
462 [1,1] . D=eeeE\-\-\-R . vhaddps %xmm2, %xmm2, %xmm3
463 [1,2] . D====eeeER . vhaddps %xmm3, %xmm3, %xmm4
464 [2,0] . DeeE\-\-\-\-\-R . vmulps %xmm0, %xmm1, %xmm2
465 [2,1] . D====eeeER . vhaddps %xmm2, %xmm2, %xmm3
466 [2,2] . D======eeeER vhaddps %xmm3, %xmm3, %xmm4
469 Average Wait times (based on the timeline view):
471 [1]: Average time spent waiting in a scheduler\(aqs queue
472 [2]: Average time spent waiting in a scheduler\(aqs queue while ready
473 [3]: Average time elapsed from WB until retire stage
476 0. 3 1.0 1.0 3.3 vmulps %xmm0, %xmm1, %xmm2
477 1. 3 3.3 0.7 1.0 vhaddps %xmm2, %xmm2, %xmm3
478 2. 3 5.7 0.0 0.0 vhaddps %xmm3, %xmm3, %xmm4
484 The timeline view is interesting because it shows instruction state changes
485 during execution. It also gives an idea of how the tool processes instructions
486 executed on the target, and how their timing information might be calculated.
488 The timeline view is structured in two tables. The first table shows
489 instructions changing state over time (measured in cycles); the second table
490 (named \fIAverage Wait times\fP) reports useful timing statistics, which should
491 help diagnose performance bottlenecks caused by long data dependencies and
492 sub\-optimal usage of hardware resources.
494 An instruction in the timeline view is identified by a pair of indices, where
495 the first index identifies an iteration, and the second index is the
496 instruction index (i.e., where it appears in the code sequence). Since this
497 example was generated using 3 iterations: \fB\-iterations=3\fP, the iteration
498 indices range from 0\-2 inclusively.
500 Excluding the first and last column, the remaining columns are in cycles.
501 Cycles are numbered sequentially starting from 0.
503 From the example output above, we know the following:
506 Instruction [1,0] was dispatched at cycle 1.
508 Instruction [1,0] started executing at cycle 2.
510 Instruction [1,0] reached the write back stage at cycle 4.
512 Instruction [1,0] was retired at cycle 10.
515 Instruction [1,0] (i.e., vmulps from iteration #1) does not have to wait in the
516 scheduler\(aqs queue for the operands to become available. By the time vmulps is
517 dispatched, operands are already available, and pipeline JFPU1 is ready to
518 serve another instruction. So the instruction can be immediately issued on the
519 JFPU1 pipeline. That is demonstrated by the fact that the instruction only
520 spent 1cy in the scheduler\(aqs queue.
522 There is a gap of 5 cycles between the write\-back stage and the retire event.
523 That is because instructions must retire in program order, so [1,0] has to wait
524 for [0,2] to be retired first (i.e., it has to wait until cycle 10).
526 In the example, all instructions are in a RAW (Read After Write) dependency
527 chain. Register %xmm2 written by vmulps is immediately used by the first
528 vhaddps, and register %xmm3 written by the first vhaddps is used by the second
529 vhaddps. Long data dependencies negatively impact the ILP (Instruction Level
532 In the dot\-product example, there are anti\-dependencies introduced by
533 instructions from different iterations. However, those dependencies can be
534 removed at register renaming stage (at the cost of allocating register aliases,
535 and therefore consuming physical registers).
537 Table \fIAverage Wait times\fP helps diagnose performance issues that are caused by
538 the presence of long latency instructions and potentially long data dependencies
539 which may limit the ILP. Note that \fBllvm\-mca\fP, by default, assumes at
540 least 1cy between the dispatch event and the issue event.
542 When the performance is limited by data dependencies and/or long latency
543 instructions, the number of cycles spent while in the \fIready\fP state is expected
544 to be very small when compared with the total number of cycles spent in the
545 scheduler\(aqs queue. The difference between the two counters is a good indicator
546 of how large of an impact data dependencies had on the execution of the
547 instructions. When performance is mostly limited by the lack of hardware
548 resources, the delta between the two counters is small. However, the number of
549 cycles spent in the queue tends to be larger (i.e., more than 1\-3cy),
550 especially when compared to other low latency instructions.
551 .SS Extra Statistics to Further Diagnose Performance Issues
553 The \fB\-all\-stats\fP command line option enables extra statistics and performance
554 counters for the dispatch logic, the reorder buffer, the retire control unit,
555 and the register file.
557 Below is an example of \fB\-all\-stats\fP output generated by MCA for the
558 dot\-product example discussed in the previous sections.
564 Dynamic Dispatch Stall Cycles:
565 RAT \- Register unavailable: 0
566 RCU \- Retire tokens unavailable: 0
567 SCHEDQ \- Scheduler full: 272
568 LQ \- Load queue full: 0
569 SQ \- Store queue full: 0
570 GROUP \- Static restrictions on the dispatch group: 0
573 Dispatch Logic \- number of cycles where we saw N instructions dispatched:
574 [# dispatched], [# cycles]
580 Schedulers \- number of cycles where we saw N instructions issued:
581 [# issued], [# cycles]
587 Scheduler\(aqs queue usage:
593 Retire Control Unit \- number of cycles where we saw N instructions retired:
594 [# retired], [# cycles]
600 Register File statistics:
601 Total number of mappings created: 900
602 Max number of mappings used: 35
604 * Register File #1 \-\- JFpuPRF:
605 Number of physical registers: 72
606 Total number of mappings created: 900
607 Max number of mappings used: 35
609 * Register File #2 \-\- JIntegerPRF:
610 Number of physical registers: 64
611 Total number of mappings created: 0
612 Max number of mappings used: 0
618 If we look at the \fIDynamic Dispatch Stall Cycles\fP table, we see the counter for
619 SCHEDQ reports 272 cycles. This counter is incremented every time the dispatch
620 logic is unable to dispatch a group of two instructions because the scheduler\(aqs
623 Looking at the \fIDispatch Logic\fP table, we see that the pipeline was only able
624 to dispatch two instructions 51.5% of the time. The dispatch group was limited
625 to one instruction 44.6% of the cycles, which corresponds to 272 cycles. The
626 dispatch statistics are displayed by either using the command option
627 \fB\-all\-stats\fP or \fB\-dispatch\-stats\fP\&.
629 The next table, \fISchedulers\fP, presents a histogram displaying a count,
630 representing the number of instructions issued on some number of cycles. In
631 this case, of the 610 simulated cycles, single
632 instructions were issued 306 times (50.2%) and there were 7 cycles where
633 no instructions were issued.
635 The \fIScheduler\(aqs queue usage\fP table shows that the maximum number of buffer
636 entries (i.e., scheduler queue entries) used at runtime. Resource JFPU01
637 reached its maximum (18 of 18 queue entries). Note that AMD Jaguar implements
641 JALU01 \- A scheduler for ALU instructions.
643 JFPU01 \- A scheduler floating point operations.
645 JLSAGU \- A scheduler for address generation.
648 The dot\-product is a kernel of three floating point instructions (a vector
649 multiply followed by two horizontal adds). That explains why only the floating
650 point scheduler appears to be used.
652 A full scheduler queue is either caused by data dependency chains or by a
653 sub\-optimal usage of hardware resources. Sometimes, resource pressure can be
654 mitigated by rewriting the kernel using different instructions that consume
655 different scheduler resources. Schedulers with a small queue are less resilient
656 to bottlenecks caused by the presence of long data dependencies.
657 The scheduler statistics are displayed by
658 using the command option \fB\-all\-stats\fP or \fB\-scheduler\-stats\fP\&.
660 The next table, \fIRetire Control Unit\fP, presents a histogram displaying a count,
661 representing the number of instructions retired on some number of cycles. In
662 this case, of the 610 simulated cycles, two instructions were retired during
663 the same cycle 399 times (65.4%) and there were 109 cycles where no
664 instructions were retired. The retire statistics are displayed by using the
665 command option \fB\-all\-stats\fP or \fB\-retire\-stats\fP\&.
667 The last table presented is \fIRegister File statistics\fP\&. Each physical register
668 file (PRF) used by the pipeline is presented in this table. In the case of AMD
669 Jaguar, there are two register files, one for floating\-point registers
670 (JFpuPRF) and one for integer registers (JIntegerPRF). The table shows that of
671 the 900 instructions processed, there were 900 mappings created. Since this
672 dot\-product example utilized only floating point registers, the JFPuPRF was
673 responsible for creating the 900 mappings. However, we see that the pipeline
674 only used a maximum of 35 of 72 available register slots at any given time. We
675 can conclude that the floating point PRF was the only register file used for
676 the example, and that it was never resource constrained. The register file
677 statistics are displayed by using the command option \fB\-all\-stats\fP or
678 \fB\-register\-file\-stats\fP\&.
680 In this example, we can conclude that the IPC is mostly limited by data
681 dependencies, and not by resource pressure.
684 This section describes the instruction flow through MCA\(aqs default out\-of\-order
685 pipeline, as well as the functional units involved in the process.
687 The default pipeline implements the following sequence of stages used to
688 process instructions.
691 Dispatch (Instruction is dispatched to the schedulers).
693 Issue (Instruction is issued to the processor pipelines).
695 Write Back (Instruction is executed, and results are written back).
697 Retire (Instruction is retired; writes are architecturally committed).
700 The default pipeline only models the out\-of\-order portion of a processor.
701 Therefore, the instruction fetch and decode stages are not modeled. Performance
702 bottlenecks in the frontend are not diagnosed. MCA assumes that instructions
703 have all been decoded and placed into a queue. Also, MCA does not model branch
705 .SS Instruction Dispatch
707 During the dispatch stage, instructions are picked in program order from a
708 queue of already decoded instructions, and dispatched in groups to the
709 simulated hardware schedulers.
711 The size of a dispatch group depends on the availability of the simulated
712 hardware resources. The processor dispatch width defaults to the value
713 of the \fBIssueWidth\fP in LLVM\(aqs scheduling model.
715 An instruction can be dispatched if:
718 The size of the dispatch group is smaller than processor\(aqs dispatch width.
720 There are enough entries in the reorder buffer.
722 There are enough physical registers to do register renaming.
724 The schedulers are not full.
727 Scheduling models can optionally specify which register files are available on
728 the processor. MCA uses that information to initialize register file
729 descriptors. Users can limit the number of physical registers that are
730 globally available for register renaming by using the command option
731 \fB\-register\-file\-size\fP\&. A value of zero for this option means \fIunbounded\fP\&.
732 By knowing how many registers are available for renaming, MCA can predict
733 dispatch stalls caused by the lack of registers.
735 The number of reorder buffer entries consumed by an instruction depends on the
736 number of micro\-opcodes specified by the target scheduling model. MCA\(aqs
737 reorder buffer\(aqs purpose is to track the progress of instructions that are
738 "in\-flight," and to retire instructions in program order. The number of
739 entries in the reorder buffer defaults to the \fIMicroOpBufferSize\fP provided by
740 the target scheduling model.
742 Instructions that are dispatched to the schedulers consume scheduler buffer
743 entries. \fBllvm\-mca\fP queries the scheduling model to determine the set
744 of buffered resources consumed by an instruction. Buffered resources are
745 treated like scheduler resources.
746 .SS Instruction Issue
748 Each processor scheduler implements a buffer of instructions. An instruction
749 has to wait in the scheduler\(aqs buffer until input register operands become
750 available. Only at that point, does the instruction becomes eligible for
751 execution and may be issued (potentially out\-of\-order) for execution.
752 Instruction latencies are computed by \fBllvm\-mca\fP with the help of the
755 \fBllvm\-mca\fP\(aqs scheduler is designed to simulate multiple processor
756 schedulers. The scheduler is responsible for tracking data dependencies, and
757 dynamically selecting which processor resources are consumed by instructions.
758 It delegates the management of processor resource units and resource groups to a
759 resource manager. The resource manager is responsible for selecting resource
760 units that are consumed by instructions. For example, if an instruction
761 consumes 1cy of a resource group, the resource manager selects one of the
762 available units from the group; by default, the resource manager uses a
763 round\-robin selector to guarantee that resource usage is uniformly distributed
764 between all units of a group.
766 \fBllvm\-mca\fP\(aqs scheduler implements three instruction queues:
769 WaitQueue: a queue of instructions whose operands are not ready.
771 ReadyQueue: a queue of instructions ready to execute.
773 IssuedQueue: a queue of instructions executing.
776 Depending on the operand availability, instructions that are dispatched to the
777 scheduler are either placed into the WaitQueue or into the ReadyQueue.
779 Every cycle, the scheduler checks if instructions can be moved from the
780 WaitQueue to the ReadyQueue, and if instructions from the ReadyQueue can be
781 issued to the underlying pipelines. The algorithm prioritizes older instructions
782 over younger instructions.
783 .SS Write\-Back and Retire Stage
785 Issued instructions are moved from the ReadyQueue to the IssuedQueue. There,
786 instructions wait until they reach the write\-back stage. At that point, they
787 get removed from the queue and the retire control unit is notified.
789 When instructions are executed, the retire control unit flags the
790 instruction as "ready to retire."
792 Instructions are retired in program order. The register file is notified of
793 the retirement so that it can free the physical registers that were allocated
794 for the instruction during the register renaming stage.
795 .SS Load/Store Unit and Memory Consistency Model
797 To simulate an out\-of\-order execution of memory operations, \fBllvm\-mca\fP
798 utilizes a simulated load/store unit (LSUnit) to simulate the speculative
799 execution of loads and stores.
801 Each load (or store) consumes an entry in the load (or store) queue. Users can
802 specify flags \fB\-lqueue\fP and \fB\-squeue\fP to limit the number of entries in the
803 load and store queues respectively. The queues are unbounded by default.
805 The LSUnit implements a relaxed consistency model for memory loads and stores.
809 A younger load is allowed to pass an older load only if there are no
810 intervening stores or barriers between the two loads.
812 A younger load is allowed to pass an older store provided that the load does
813 not alias with the store.
815 A younger store is not allowed to pass an older store.
817 A younger store is not allowed to pass an older load.
820 By default, the LSUnit optimistically assumes that loads do not alias
821 (\fI\-noalias=true\fP) store operations. Under this assumption, younger loads are
822 always allowed to pass older stores. Essentially, the LSUnit does not attempt
823 to run any alias analysis to predict when loads and stores do not alias with
826 Note that, in the case of write\-combining memory, rule 3 could be relaxed to
827 allow reordering of non\-aliasing store operations. That being said, at the
828 moment, there is no way to further relax the memory model (\fB\-noalias\fP is the
829 only option). Essentially, there is no option to specify a different memory
830 type (e.g., write\-back, write\-combining, write\-through; etc.) and consequently
831 to weaken, or strengthen, the memory model.
833 Other limitations are:
836 The LSUnit does not know when store\-to\-load forwarding may occur.
838 The LSUnit does not know anything about cache hierarchy and memory types.
840 The LSUnit does not know how to identify serializing operations and memory
844 The LSUnit does not attempt to predict if a load or store hits or misses the L1
845 cache. It only knows if an instruction "MayLoad" and/or "MayStore." For
846 loads, the scheduling model provides an "optimistic" load\-to\-use latency (which
847 usually matches the load\-to\-use latency for when there is a hit in the L1D).
849 \fBllvm\-mca\fP does not know about serializing operations or memory\-barrier
850 like instructions. The LSUnit conservatively assumes that an instruction which
851 has both "MayLoad" and unmodeled side effects behaves like a "soft"
852 load\-barrier. That means, it serializes loads without forcing a flush of the
853 load queue. Similarly, instructions that "MayStore" and have unmodeled side
854 effects are treated like store barriers. A full memory barrier is a "MayLoad"
855 and "MayStore" instruction with unmodeled side effects. This is inaccurate, but
856 it is the best that we can do at the moment with the current information
859 A load/store barrier consumes one entry of the load/store queue. A load/store
860 barrier enforces ordering of loads/stores. A younger load cannot pass a load
861 barrier. Also, a younger store cannot pass a store barrier. A younger load
862 has to wait for the memory/load barrier to execute. A load/store barrier is
863 "executed" when it becomes the oldest entry in the load/store queue(s). That
864 also means, by construction, all of the older loads/stores have been executed.
866 In conclusion, the full set of load/store consistency rules are:
869 A store may not pass a previous store.
871 A store may not pass a previous load (regardless of \fB\-noalias\fP).
873 A store has to wait until an older store barrier is fully executed.
875 A load may pass a previous load.
877 A load may not pass a previous store unless \fB\-noalias\fP is set.
879 A load has to wait until an older load barrier is fully executed.
882 Maintained by The LLVM Team (http://llvm.org/).
884 2003-2018, LLVM Project
885 .\" Generated by docutils manpage writer.
projects / FreeBSD / FreeBSD.git / blob