summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-mca/BackendStatistics.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-mca] Renamed BackendStatistics to RetireControlUnitStatistics.Andrea Di Biagio2018-04-111-50/+0
| | | | | | Also, removed flag -verbose in favor of flag -retire-stats. llvm-svn: 329794
* [llvm-mca] Move the logic that prints scheduler statistics from ↵Andrea Di Biagio2018-04-111-75/+2
| | | | | | | | BackendStatistics to its own view. Added flag -scheduler-stats to print scheduler related statistics. llvm-svn: 329792
* [llvm-mca] Move the logic that prints dispatch unit statistics from ↵Andrea Di Biagio2018-04-101-44/+1
| | | | | | | | | | | BackendStatistics to its own view. This patch moves the logic that collects and analyzes dispatch events to the DispatchStatistics view. Added flag -dispatch-stats to print statistics related to the dispatch logic. llvm-svn: 329708
* [llvm-mca] Move the logic that prints register file statistics to its own ↵Andrea Di Biagio2018-04-031-74/+0
| | | | | | | | | | | | | view. NFCI Before this patch, the "BackendStatistics" view was responsible for printing the register file usage (as well as many other statistics). Now users can enable register file usage statistics using the command line flag `-register-file-stats`. By default, the tool doesn't print register file statistics. llvm-svn: 329083
* [MC][Tablegen] Allow the definition of processor register files in the ↵Andrea Di Biagio2018-04-031-6/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scheduling model for llvm-mca This patch allows the description of register files in processor scheduling models. This addresses PR36662. A new tablegen class named 'RegisterFile' has been added to TargetSchedule.td. Targets can optionally describe register files for their processors using that class. In particular, class RegisterFile allows to specify: - The total number of physical registers. - Which target registers are accessible through the register file. - The cost of allocating a register at register renaming stage. Example (from this patch - see file X86/X86ScheduleBtVer2.td) def FpuPRF : RegisterFile<72, [VR64, VR128, VR256], [1, 1, 2]> Here, FpuPRF describes a register file for MMX/XMM/YMM registers. On Jaguar (btver2), a YMM register definition consumes 2 physical registers, while MMX/XMM register definitions only cost 1 physical register. The syntax allows to specify an empty set of register classes. An empty set of register classes means: this register file models all the registers specified by the Target. For each register class, users can specify an optional register cost. By default, register costs default to 1. A value of 0 for the number of physical registers means: "this register file has an unbounded number of physical registers". This patch is structured in two parts. * Part 1 - MC/Tablegen * A first part adds the tablegen definition of RegisterFile, and teaches the SubtargetEmitter how to emit information related to register files. Information about register files is accessible through an instance of MCExtraProcessorInfo. The idea behind this design is to logically partition the processor description which is only used by external tools (like llvm-mca) from the processor information used by the llvm machine schedulers. I think that this design would make easier for targets to get rid of the extra processor information if they don't want it. * Part 2 - llvm-mca related * The second part of this patch is related to changes to llvm-mca. The main differences are: 1) class RegisterFile now needs to take into account the "cost of a register" when allocating physical registers at register renaming stage. 2) Point 1. triggered a minor refactoring which lef to the removal of the "maximum 32 register files" restriction. 3) The BackendStatistics view has been updated so that we can print out extra details related to each register file implemented by the processor. The effect of point 3. is also visible in tests register-files-[1..5].s. Differential Revision: https://reviews.llvm.org/D44980 llvm-svn: 329067
* [llvm-mca] Move the logic that computes the register file usage to the ↵Andrea Di Biagio2018-03-211-12/+31
| | | | | | | | | | | | | | | | | | | | | | | BackendStatistics view. With this patch, the "instruction dispatched" event now provides information related to the number of microarchitectural registers used in each register file. Similarly, the "instruction retired" event is now able to tell how may registers are freed in each register file. Currently, the BackendStatistics view is the only consumer of register usage/pressure information. BackendStatistics uses that info to print out a few general statistics (i.e. max number of mappings used; total mapping created). Before this patch, the BackendStatistics was forced to query the Backend to obtain the register pressure information. This helps removes that dependency. Now views are completely independent from the Backend. As a consequence, it should be easier to address PR36663 and further modularize the pipeline. Added a couple of test cases in the BtVer2 specific directory. llvm-svn: 328129
* [llvm-mca] Move the logic that computes the scheduler's queue usage to the ↵Andrea Di Biagio2018-03-201-11/+30
| | | | | | | | | | | | | | | | | | | | | | BackendStatistics view. This patch introduces two new callbacks in the event listener interface to handle the "buffered resource reserved" event and the "buffered resource released" event. Every time a buffered resource is used, an event is generated. Before this patch, the Scheduler (with the help of the ResourceManager) was responsible for tracking the scheduler's queue usage. However, that design forced the Scheduler to 'publish' scheduler's queue pressure information through the Backend interface. The goal of this patch is to break the dependency between the BackendStatistics view, and the Backend. Now the Scheduler knows how to notify "buffer reserved/released" events. The scheduler's queue usage analysis has been moved to the BackendStatistics. Differential Revision: https://reviews.llvm.org/D44686 llvm-svn: 328011
* [llvm-mca] Add pipeline stall events.Andrea Di Biagio2018-03-191-12/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new class named HWStallEvent (see HWEventListener.h), and updates the event listener interface. A HWStallEvent represents a pipeline stall caused by the lack of hardware resources. Similarly to HWInstructionEvent, the event type is an unsigned, and the exact meaning depends on the subtarget. At the moment, HWStallEvent supports a few generic dispatch events. The main goals of this patch is to remove the logic that counts dispatch stalls from the DispatchUnit to the BackendStatistics view. Previously, DispatchUnit was responsible for counting and classifying dispatch stall events. With this patch, we delegate the task of counting and classifying stall events to the listeners (i.e. in our case, it is view "BackendStatistics"). So, the DispatchUnit doesn't have to do extra (unnecessary) bookkeeping. This patch also helps futher simplifying the Backend interface. Now class BackendStatistics no longer has to query the Backend interface to obtain the number of dispatch stalls. As a consequence, we can get rid of all the 'getNumXXX()' methods from class Backend. The long term goal is to remove all the remaining dependencies between the Backend and the BackendStatistics interface. Differential Revision: https://reviews.llvm.org/D44621 llvm-svn: 327837
* [llvm-mca] Refactor event listeners to make the backend agnostic to event types.Clement Courbet2018-03-131-0/+16
| | | | | | | | | | Summary: This is a first step towards making the pipeline configurable. Subscribers: llvm-commits, andreadb Differential Revision: https://reviews.llvm.org/D44309 llvm-svn: 327389
* [llvm-mca] BackendStatistics: early exit from method printSchedulerUsage if theAndrea Di Biagio2018-03-101-0/+9
| | | | | | no scheduler resources were consumed. llvm-svn: 327215
* [llvm-mca] Views are now independent from resource masks. NFCIAndrea Di Biagio2018-03-101-2/+1
| | | | | | | | | This change removes method Backend::getProcResourceMasks() and simplifies some logic in the Views. This effectively removes yet another dependency between the views and the Backend. No functional change intended. llvm-svn: 327214
* [llvm-mca] Run clang-format on the source code. NFCAndrea Di Biagio2018-03-091-12/+14
| | | | llvm-svn: 327125
* [llvm-mca] Unify the API for the various views. NFCIAndrea Di Biagio2018-03-081-0/+59
| | | | | | | | | | | | | | | This allows the customization of the performance report. Users can specify their own custom sequence of views. Each view contributes a portion of the performance report generated by the BackendPrinter. Internally, class BackendPrinter keeps a sequence of views; views are printed out in sequence when method 'printReport()' is called. This patch addresses one of the two review comments from Clement in D43951. llvm-svn: 327018
* [llvm-mca] LLVM Machine Code Analyzer.Andrea Di Biagio2018-03-081-0/+79
llvm-mca is an LLVM based performance analysis tool that can be used to statically measure the performance of code, and to help triage potential problems with target scheduling models. llvm-mca uses information which is already available in LLVM (e.g. scheduling models) to statically measure the performance of machine code in a specific cpu. Performance is measured in terms of throughput as well as processor resource consumption. The tool currently works for processors with an out-of-order backend, for which there is a scheduling model available in LLVM. The main goal of this tool is not just to predict the performance of the code when run on the target, but also help with diagnosing potential performance issues. Given an assembly code sequence, llvm-mca estimates the IPC (instructions per cycle), as well as hardware resources pressure. The analysis and reporting style were mostly inspired by the IACA tool from Intel. This patch is related to the RFC on llvm-dev visible at this link: http://lists.llvm.org/pipermail/llvm-dev/2018-March/121490.html Differential Revision: https://reviews.llvm.org/D43951 llvm-svn: 326998
OpenPOWER on IntegriCloud