summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-mca/Backend.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-mca] Rename Backend to Pipeline. NFC.Matt Davis2018-06-251-111/+0
| | | | | | | | | | | | | | | | | | Summary: This change renames the Backend and BackendPrinter to Pipeline and PipelinePrinter respectively. Variables and comments have also been updated to reflect this change. The reason for this rename, is to be slightly more correct about what MCA is modeling. MCA models a Pipeline, which implies some logical sequence of stages. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb, courbet Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D48496 llvm-svn: 335496
* [llvm-mca] Introduce a sequential container of StagesMatt Davis2018-06-221-13/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Remove explicit stages and introduce a list of stages. A pipeline should be composed of an arbitrary list of stages, and not any predefined list of stages in the Backend. The Backend should not know of any particular stage, rather it should only be concerned that it has a list of stages, and that those stages will fulfill the contract of what it means to be a Stage (namely pre/post/execute a given instruction). For now, we leave the original set of stages defined in the Backend ctor; however, I imagine these will be moved out at a later time. This patch makes an adjustment to the semantics of Stage::isReady. Specifically, what the Backend really needs to know is if a Stage has unfinished work. With that said, it is more appropriately renamed Stage::hasWorkToComplete(). This change will clean up the check in Backend::run(), allowing us to query each stage to see if there is unfinished work, regardless of what subclass a stage might be. I feel that this change simplifies the semantics too, but that's a subjective statement. Given how RetireStage and ExecuteStage handle data in their preExecute(), I've had to change the order of Retire and Execute in our stage list. Retire must complete any of its preExecute actions before ExecuteStage's preExecute can take control. This is mainly because both stages utilize the RCU. In the meantime, I want to see if I can adjust that or remove that coupling. Reviewers: andreadb, RKSimon, courbet Reviewed By: andreadb Subscribers: tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D46907 llvm-svn: 335361
* [llvm-mca] Introduce the ExecuteStage (was originally the Scheduler class).Matt Davis2018-06-141-3/+2
| | | | | | | | | | | | | | Summary: This patch transforms the Scheduler class into the ExecuteStage. Most of the logic remains. Reviewers: andreadb, RKSimon, courbet Reviewed By: andreadb Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D47246 llvm-svn: 334679
* [llvm-mca] Add the RetireStage. Matt Davis2018-05-251-0/+5
| | | | | | | | | | | | | | | | | Summary: This class maintains the same logic as the original RetireControlUnit. This is just an intermediate patch to make the RCU a Stage. Future patches will remove the dependency on the DispatchStage, and then more properly populate the pre/execute/post Stage interface. Reviewers: andreadb, RKSimon, courbet Reviewed By: andreadb, courbet Subscribers: javed.absar, mgorny, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D47244 llvm-svn: 333292
* [llvm-mca] Move DispatchStage::cycleEvent to preExecute. NFC.Matt Davis2018-05-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: This is an intermediate change, it moves the non-notification logic from Backend::notifyCycleBegin to runCycle(). Once the scheduler becomes part of the Execution stage the explicit call to Scheduler::cycleEvent will disappear. The logic for Dispatch::cycleEvent() can be in the preExecute phase, which this patch addresses. Reviewers: andreadb, RKSimon, courbet Reviewed By: andreadb Subscribers: tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D47213 llvm-svn: 333029
* [llvm-mca] Make Dispatch a subclass of Stage.Matt Davis2018-05-171-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The logic of dispatch remains the same, but now DispatchUnit is a Stage (DispatchStage). This change has the benefit of simplifying the backend runCycle() code. The same logic applies, but it belongs to different components now. This is just a start, eventually we will need to remove the call to the DispatchStage in Scheduler.cpp, but that will be a separate patch. This change is mostly a renaming and moving of existing logic. This change also encouraged me to remove the Subtarget (STI) member from the Backend class. That member was used to initialize the other members of Backend and to eventually call DispatchUnit::dispatch(). Now that we have Stages, we can eliminate this by instantiating the DispatchStage with everything it needs at the time of construction (e.g., Subtarget). That change allows us to call DispatchStage::execute(IR) as we expect to call execute() for all other stages. Once we add the Stage list (D46907) we can more cleanly call preExecute() on all of the stages, DispatchStage, will probably wrap cycleEvent() in that case. Made some formatting and minor cleanups to README.txt. Some of the text was re-flowed to stay within 80 cols. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb, courbet Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D46983 llvm-svn: 332652
* [llvm-mca] Introduce a pipeline Stage class and FetchStage.Matt Davis2018-05-151-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is just an idea, really two ideas. I expect some push-back, but I realize that posting a diff is the most comprehensive way to express these concepts. This patch introduces a Stage class which represents the various stages of an instruction pipeline. As a start, I have created a simple FetchStage that is based on existing logic for how MCA produces instructions, but now encapsulated in a Stage. The idea should become more concrete once we introduce additional stages. The idea being, that when a stage completes, the next stage in the pipeline will be executed. Stages are chained together as a singly linked list to closely model a real pipeline. For now there is only one stage, so the stage-to-stage flow of instructions isn't immediately obvious. Eventually, Stage will also handle event notifications, but that functionality is not complete, and not destined for this patch. Ideally, an interested party can register for notifications from a particular stage. Callbacks will be issued to these listeners at various points in the execution of the stage. For now, eventing functionality remains similar to what it has been in mca::Backend. We will be building-up the Stage class as we move on, such as adding debug output. This patch also removes the unique_ptr<Instruction> return value from InstrBuilder::createInstruction. An Instruction pointer is still produced, but now it's up to the caller to decide how that item should be managed post-allocation (e.g., smart pointer). This allows the Fetch stage to create instructions and manage the lifetime of those instructions as it wishes, and not have to be bound to any specific managed pointer type. Other callers of createInstruction might have different requirements, and thus can manage the pointer to fit their needs. Another idea would be to push the ownership to the RCU. Currently, the FetchStage will wrap the Instruction pointer in a shared_ptr. This allows us to remove the Instruction container in Backend, which was probably going to disappear, or move, at some point anyways. Note that I did run these changes through valgrind, to make sure we are not leaking memory. While the shared_ptr comes with some additional overhead it relieves us from having to manage a list of generated instructions, and/or make lookup calls to remove the instructions. I realize that both the Stage class and the Instruction pointer management (mentioned directly above) are separate but related ideas, and probably should land as separate patches; I am happy to do that if either idea is decent. The main reason these two ideas are together is that Stage::execute() can mutate an InstRef. For the fetch stage, the InstRef is populated as the primary action of that stage (execute()). I didn't want to change the Stage interface to support the idea of generating an instruction. Ideally, instructions are to be pushed through the pipeline. I didn't want to draw too much of a specialization just for the fetch stage. Excuse the word-salad. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: llvm-commits, mgorny, javed.absar, tschuett, gbedwell Differential Revision: https://reviews.llvm.org/D46741 llvm-svn: 332390
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-4/+4
| | | | | | | | | | | | | | | | The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it. In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one. Differential Revision: https://reviews.llvm.org/D43624 llvm-svn: 332240
* [llvm-mca] Avoid exposing index values in the MCA interfaces.Matt Davis2018-05-071-8/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch eliminates many places where we originally needed to pass index values to represent an instruction. The index is still used as a key, in various parts of MCA. I'm not comfortable eliminating the index just yet. By burying the index in the instruction, we can avoid exposing that value in many places. Eventually, we should consider removing the Instructions list in the Backend all together, it's only used to hold and reclaim the memory for the allocated Instruction instances. Instead we could pass around a smart pointer. But that's a separate discussion/patch. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D46367 llvm-svn: 331660
* [llvm-mca] remove unused argument from method InstrBuilder::createInstrDescImpl.Andrea Di Biagio2018-05-041-2/+1
| | | | | | | | | We don't need to pass the instruction index to the method that constructs new instruction descriptors. No functional change intended. llvm-svn: 331516
* [llvm-mca] Removed unused argument from cycleEvent. NFCAndrea Di Biagio2018-04-121-4/+4
| | | | llvm-svn: 329895
* [llvm-mca] Pass the InstrBuilder to the constructor of Backend.Andrea Di Biagio2018-03-231-1/+1
| | | | | | | This is done in preparation for the fix for PR36784. No functional change. llvm-svn: 328306
* [llvm-mca] Simplify (and better standardize) the Instruction interface.Andrea Di Biagio2018-03-221-1/+1
| | | | llvm-svn: 328190
* [llvm-mca] Move the logic that computes the scheduler's queue usage to the ↵Andrea Di Biagio2018-03-201-0/+10
| | | | | | | | | | | | | | | | | | | | | | 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] Use llvm::make_unique in a few places. NFCAndrea Di Biagio2018-03-201-3/+2
| | | | | | Also, clang-format a couple of DEBUG functions. llvm-svn: 327978
* [llvm-mca] Move the routine that computes processor resource masks to its ↵Andrea Di Biagio2018-03-201-1/+1
| | | | | | | | | | | | | | | | | | own file. Function computeProcResourceMasks is used by the ResourceManager (owned by the Scheduler) to compute resource masks for processor resources. Before this refactoring, there was an implicit dependency between the Scheduler and the InstrBuilder. That is because InstrBuilder has to know about resource masks when computing the set of processor resources consumed by a new instruction. With this patch, the functionality that computes resource masks has been extracted from the ResourceManager, and moved to a separate file (Support.h). This helps removing the dependency between the Scheduler and the InstrBuilder. No functional change intended. llvm-svn: 327973
* [llvm-mca] Add pipeline stall events.Andrea Di Biagio2018-03-191-1/+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] Simplify code. NFC.Andrea Di Biagio2018-03-151-1/+1
| | | | | | | | Now both method DispatchUnit::checkRAT() and DispatchUnit::canDispatch take as input an Instruction refrence instead of an instruction descriptor. This was requested by Simon in D44488 to simplify the diff. llvm-svn: 327640
* [llvm-mca] Move the logic that updates the register files from InstrBuilder ↵Andrea Di Biagio2018-03-141-18/+10
| | | | | | | | | | | | | | | | | | | to DispatchUnit. NFCI Before this patch, the register file was always updated at instruction creation time. That means, new read-after-write dependencies, and new temporary registers were allocated at instruction creation time. This patch refactors the code in InstrBuilder, and move all the logic that updates the register file into the dispatch unit. We only want to update the register file when instructions are effectively dispatched (not before). This refactoring also helps removing a bad dependency between the InstrBuilder and the DispatchUnit. No functional change intended. llvm-svn: 327514
* [llvm-mca] Refactor event listeners to make the backend agnostic to event types.Clement Courbet2018-03-131-43/+2
| | | | | | | | | | 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] Fix handling of zero-latency instructions.Andrea Di Biagio2018-03-081-5/+0
| | | | | | | | | | | | | | | | | | | | This patch fixes a problem found when testing zero latency instructions on target AArch64 -mcpu=exynos-m3 / -mcpu=exynos-m1. On Exynos-m3/m1, direct branches are zero-latency instructions that don't consume any processor resources. The DispatchUnit marks zero-latency instructions as "executed", so that no scheduling is required. The event of instruction executed is then notified to all the listeners, and the reorder buffer (managed by the RetireControlUnit) is updated. In particular, the entry associated to the zero-latency instruction in the reorder buffer is marked as executed. Before this patch, the DispatchUnit forgot to assign a retire control unit token (RCUToken) to the zero-latency instruction. As a consequence, the RCUToken was used uninitialized. This was causing a crash in the RetireControlUnit logic. Fixes PR36650. llvm-svn: 327056
* [llvm-mca] Unify the API for the various views. NFCIAndrea Di Biagio2018-03-081-5/+5
| | | | | | | | | | | | | | | 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/+132
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