summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-mca/include
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-mca] Move llvm-mca library to llvm/lib/MCA.Clement Courbet2018-12-1719-2661/+0
| | | | | | | | | | | | Summary: See PR38731. Reviewers: andreadb Subscribers: mgorny, javed.absar, tschuett, gbedwell, andreadb, RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D55557 llvm-svn: 349332
* [llvm-mca] Speedup the default resource selection strategy.Andrea Di Biagio2018-11-301-3/+3
| | | | | | | | | This patch removes a (potentially) slow while loop in DefaultResourceStrategy::select(). A better (and faster) approach is to do some bit manipulation in order to shrink the range of candidate resources. On a release build, this change gives an average speedup of ~10%. llvm-svn: 348007
* [llvm-mca] Simplify code in class Scheduler. NFCIAndrea Di Biagio2018-11-302-12/+12
| | | | llvm-svn: 347985
* [llvm-mca][MC] Add the ability to declare which processor resources model ↵Andrea Di Biagio2018-11-291-2/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | load/store queues (PR36666). This patch adds the ability to specify via tablegen which processor resources are load/store queue resources. A new tablegen class named MemoryQueue can be optionally used to mark resources that model load/store queues. Information about the load/store queue is collected at 'CodeGenSchedule' stage, and analyzed by the 'SubtargetEmitter' to initialize two new fields in struct MCExtraProcessorInfo named `LoadQueueID` and `StoreQueueID`. Those two fields are identifiers for buffered resources used to describe the load queue and the store queue. Field `BufferSize` is interpreted as the number of entries in the queue, while the number of units is a throughput indicator (i.e. number of available pickers for loads/stores). At construction time, LSUnit in llvm-mca checks for the presence of extra processor information (i.e. MCExtraProcessorInfo) in the scheduling model. If that information is available, and fields LoadQueueID and StoreQueueID are set to a value different than zero (i.e. the invalid processor resource index), then LSUnit initializes its LoadQueue/StoreQueue based on the BufferSize value declared by the two processor resources. With this patch, we more accurately track dynamic dispatch stalls caused by the lack of LS tokens (i.e. load/store queue full). This is also shown by the differences in two BdVer2 tests. Stalls that were previously classified as generic SCHEDULER FULL stalls, are not correctly classified either as "load queue full" or "store queue full". About the differences in the -scheduler-stats view: those differences are expected, because entries in the load/store queue are not released at instruction issue stage. Instead, those are released at instruction executed stage. This is the main reason why for the modified tests, the load/store queues gets full before PdEx is full. Differential Revision: https://reviews.llvm.org/D54957 llvm-svn: 347857
* Reapply "[llvm-mca] Return the total number of cycles from method ↵Andrea Di Biagio2018-11-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | Pipeline::run()." This reapplies r347767 (originally reviewed at: https://reviews.llvm.org/D55000) with a fix for the missing std::move of the Error returned by the call to Pipeline::runCycle(). Below is the original commit message from r347767. If a user only cares about the overall latency, then the best/quickest way is to change method Pipeline::run() so that it returns the total number of cycles to the caller. When the simulation pipeline is run, the number of cycles (or an error) is returned from method Pipeline::run(). The advantage is that no hardware event listener is needed for computing that latency. So, the whole process should be faster (and simpler - at least for that particular use case). llvm-svn: 347795
* Revert [llvm-mca] Return the total number of cycles from method Pipeline::run().Andrea Di Biagio2018-11-281-4/+1
| | | | | | This reverts commits 347767. llvm-svn: 347775
* [llvm-mca] Return the total number of cycles from method Pipeline::run().Andrea Di Biagio2018-11-281-1/+4
| | | | | | | | | | | | | | If a user only cares about the overall latency, then the best/quickest way is to change method Pipeline::run() so that it returns the total number of cycles to the caller. When the simulation pipeline is run, the number of cycles (or an error) is returned from method Pipeline::run(). The advantage is that no hardware event listener is needed for computing that latency. So, the whole process should be faster (and simpler - at least for that particular use case). llvm-svn: 347767
* [llvm-mca] InstrBuilder: warnings for call/ret instructions are only ↵Andrea Di Biagio2018-11-241-1/+8
| | | | | | reported once. llvm-svn: 347514
* [llvm-mca] Refactor some of the logic in InstrBuilder, and add a ↵Andrea Di Biagio2018-11-231-2/+2
| | | | | | | | | | | | | | | | | | | | verifyOperands method. With this change, InstrBuilder emits an error if the MCInst sequence contains an instruction with a variadic opcode, and a non-zero number of variadic operands. Currently we don't know how to correctly analyze variadic opcodes. The problem with variadic operands is that there is no information for them in the opcode descriptor (i.e. MCInstrDesc). That means, we don't know which variadic operands are defs, and which are uses. In future, we could try to conservatively assume that any extra register operands is both a register use and a register definition. This patch fixes a subtle bug in the evaluation of read/write operands for ARM VLD1 with implicit index update. Added test vld1-index-update.s llvm-svn: 347503
* [llvm-mca] LSUnit: use a SmallSet to model load/store queues. NFCIAndrea Di Biagio2018-11-221-5/+5
| | | | | | | | | | Also, try to minimize the number of queries to the memory queues to speedup the analysis. On average, this change gives a small 2% speedup. For memcpy-like kernels, the speedup is up to 5.5%. llvm-svn: 347469
* [llvm-mca] Use a SmallVector instead of std::vector to track register ↵Andrea Di Biagio2018-11-221-7/+6
| | | | | | | | | | reads/writes. NFCI This avoids a heap allocation most of the times. This patch gives a small but consistent 3% speedup on a release build (up to ~5% on a debug build). llvm-svn: 347464
* [llvm-mca] Fix an invalid memory read introduced by r346487.Andrea Di Biagio2018-11-221-7/+21
| | | | | | | | | | | | | | | | | | | | This patch fixes an invalid memory read introduced by r346487. Before this patch, partial register write had to query the latency of the dependent full register write by calling a method on the full write descriptor. However, if the full write is from an already retired instruction, chances are that the EntryStage already reclaimed its memory. In some parial register write tests, valgrind was reporting an invalid memory read. This change fixes the invalid memory access problem. Writes are now responsible for tracking dependent partial register writes, and notify them in the event of instruction issued. That means, partial register writes no longer need to query their associated full write to check when they are ready to execute. Added test X86/BtVer2/partial-reg-update-7.s llvm-svn: 347459
* [llvm-mca] Use a small vector for instructions in the EntryStage.Andrea Di Biagio2018-11-091-4/+4
| | | | | | | | | | | | | | | | | | | | | Use a simple SmallVector to track the lifetime of simulated instructions. An ordered map was not needed because instructions are already picked in program order. It is also much faster if we avoid searching for already retired instructions at the end of every cycle. The new policy only triggers a "garbage collection" when the number of retired instructions becomes significantly big when compared with the total size of the vector. While working on this, I noticed that instructions were correctly retired, but their internal state was not updated (i.e. there was no transition from the EXECUTED state, to the RETIRED state). While this was not a problem for the views, it prevented the EntryStage from correctly garbage collecting already retired instructions. That was a bad oversight, and this patch fixes it. The observed speedup on a debug build of llvm-mca after this patch is ~6%. On a release build of llvm-mca, the observed speedup is ~%15%. llvm-svn: 346487
* [llvm-mca] PR39261: Rename FetchStage to EntryStage.Andrea Di Biagio2018-11-081-9/+10
| | | | | | | | | | | | This fixes PR39261. FetchStage is a misnomer. It causes confusion with the frontend fetch stage, which we don't currently simulate. I decided to rename it into EntryStage mainly because this is meant to be a "source" stage for all pipelines. Differential Revision: https://reviews.llvm.org/D54268 llvm-svn: 346419
* [llvm-mca] Add extra counters for move elimination in view ↵Andrea Di Biagio2018-11-013-9/+30
| | | | | | | | | | | | | | | | | | RegisterFileStatistics. This patch teaches view RegisterFileStatistics how to report events for optimizable register moves. For each processor register file, view RegisterFileStatistics reports the following extra information: - Number of optimizable register moves - Number of register moves eliminated - Number of zero moves (i.e. register moves that propagate a zero) - Max Number of moves eliminated per cycle. Differential Revision: https://reviews.llvm.org/D53976 llvm-svn: 345865
* [llvm-mca] Remove namespace prefixes made redundant by r345612. NFCAndrea Di Biagio2018-10-3118-149/+129
| | | | llvm-svn: 345730
* [llvm-mca] Move namespace mca inside llvm::Fangrui Song2018-10-3019-0/+38
| | | | | | | | | | | | | | | | Summary: This allows to remove `using namespace llvm;` in those *.cpp files When we want to revisit the decision (everything resides in llvm::mca::*) in the future, we can move things to a nested namespace of llvm::mca::, to conceptually make them separate from the rest of llvm::mca::* Reviewers: andreadb, mattd Reviewed By: andreadb Subscribers: javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D53407 llvm-svn: 345612
* [llvm-mca] Lower to mca::Instructon before the pipeline is run.Andrea Di Biagio2018-10-293-26/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, the lowering of instructions from llvm::MCInst to mca::Instruction was done as part of the first stage of the pipeline (i.e. the FetchStage). In particular, FetchStage was responsible for picking the next instruction from the source sequence, and lower it to an mca::Instruction with the help of an object of class InstrBuilder. The dependency on InstrBuilder was problematic for a number of reasons. Class InstrBuilder only knows how to lower from llvm::MCInst to mca::Instruction. That means, it is hard to support a different scenario where instructions in input are not instances of class llvm::MCInst. Even if we managed to specialize InstrBuilder, and generalize most of its internal logic, the dependency on InstrBuilder in FetchStage would have caused more troubles (other than complicating the pipeline logic). With this patch, the lowering step is done before the pipeline is run. The pipeline is no longer responsible for lowering from MCInst to mca::Instruction. As a consequence of this, the FetchStage no longer needs to interact with an InstrBuilder. The mca::SourceMgr class now simply wraps a reference to a sequence of mca::Instruction objects. This simplifies the logic of FetchStage, and increases the usability of it. As a result, on a debug build, we see a 7-9% speedup; on a release build, the speedup is around 3-4%. llvm-svn: 345500
* [llvm-mca] Removed dependency on mca::SourcMgr in some Views. NFCAndrea Di Biagio2018-10-261-2/+1
| | | | llvm-svn: 345376
* [llvm-mca] Introduce a new base class for mca::Instruction, and change how ↵Andrea Di Biagio2018-10-251-50/+56
| | | | | | | | | | | | | | | | | | | | | read/write information is stored. This patch introduces a new base class for Instruction named InstructionBase. Class InstructionBase is responsible for tracking data dependencies with the help of ReadState and WriteState objects. Class Instruction now derives from InstructionBase, and adds extra information related to the `InstrStage` as well as the `RCUTokenID`. ReadState and WriteState objects are no longer unique pointers. This avoids extra heap allocation and pointer checks that weren't really needed. Now, those objects are simply stored into SmallVectors. We use a SmallVector instead of a std::vector because we expect most instructions to only have a very small number of reads and writes. By using a simple SmallVector we also avoid extra heap allocations most of the time. In a debug build, this improves the performance of llvm-mca by roughly 10% (I still have to verify the impact in performance on a release build). llvm-svn: 345280
* [llvm-mca] Removed a couple of redundant method declarations, and simplified ↵Andrea Di Biagio2018-10-251-14/+2
| | | | | | code in ResourcePressureView. NFC llvm-svn: 345259
* [llvm-mca] Replace InstRef::isValid with operator bool. NFC.Matt Davis2018-10-241-1/+1
| | | | llvm-svn: 345190
* [llvm-mca] Simplify the logic in FetchStage. NFCIAndrea Di Biagio2018-10-241-1/+1
| | | | | | Only method 'getNextInstruction()' needs to interact with the SourceMgr. llvm-svn: 345185
* [llvm-mca] Remove dependency from InstrBuilder in class InstructionTables.Andrea Di Biagio2018-10-242-6/+6
| | | | | | | | | Also, removed the initialization of vectors used for processor resource masks. Support function 'computeProcResourceMasks()' already calls method resize on those vectors. No functional change intended. llvm-svn: 345161
* [llvm-mca] Refactor class SourceMgr. NFCIAndrea Di Biagio2018-10-241-15/+7
| | | | | | | | Added begin()/end() methods to allow the usage of SourceMgr in foreach loops. With this change, method getMCInstFromIndex() (as well as a couple of other methods) are now redundant, and can be removed from the public interface. llvm-svn: 345147
* [llvm-mca] [llvm-mca] Improved error handling and error reporting from class ↵Andrea Di Biagio2018-10-242-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | InstrBuilder. A new class named InstructionError has been added to Support.h in order to improve the error reporting from class InstrBuilder. The llvm-mca driver is responsible for handling InstructionError objects, and printing them out to stderr. The goal of this patch is to remove all the remaining error handling logic from the library code. In particular, this allows us to: - Simplify the logic in InstrBuilder by removing a needless dependency from MCInstrPrinter. - Centralize all the error halding logic in a new function named 'runPipeline' (see llvm-mca.cpp). This is also a first step towards generalizing class InstrBuilder, so that in future, we will be able to reuse its logic to also "lower" MachineInstr to mca::Instruction objects. Differential Revision: https://reviews.llvm.org/D53585 llvm-svn: 345129
* [llvm-mca] Use llvm::ArrayRef in class SourceMgr. NFCIAndrea Di Biagio2018-10-221-7/+7
| | | | | | | Class SourceMgr now uses type ArrayRef<MCInst> to reference the sequence of code from a "CodeRegion". llvm-svn: 344911
* [llvm-mca] Remove a stale TODO comment. NFCAndrea Di Biagio2018-10-191-2/+0
| | | | | | | Starting from revision r344334, we can now describe optimizable register-register moves in the machine scheduling models. llvm-svn: 344797
* [llvm-mca] Correctly set aliases for register writes introduced by optimized ↵Andrea Di Biagio2018-10-121-1/+7
| | | | | | | | | | | register moves. This fixes a problem introduced by r344334. A write from a non-zero move eliminated at register renaming stage was not correctly handled by the PRF. This would have led to an assertion failure if the processor model declares a PRF that enables non-zero move elimination. llvm-svn: 344392
* [llvm-mca] Minor refactoring in preparation for a patch that will fully fix ↵Andrea Di Biagio2018-10-101-5/+6
| | | | | | PR36671. NFCI llvm-svn: 344149
* [llvm-mca] Remove unused/stale forward decl. NFC.Matt Davis2018-10-041-2/+0
| | | | llvm-svn: 343823
* [llvm-mca] Move field 'AllowZeroMoveEliminationOnly' to class RegisterFile. NFC.Andrea Di Biagio2018-10-041-4/+4
| | | | | | | | | | | | | | | | Flag 'AllowZeroMoveEliminationOnly' should have been a property of the PRF, and not set at register granularity. This change also restricts move elimination to writes that update a full physical register. We assume that there is a strong correlation between logical registers that allow move elimination, and how those same registers are allocated to physical registers by the register renamer. This is still a no functional change, because this experimental code path is disabled for now. This is done in preparation for another patch that will add the ability to describe how move elimination works in scheduling models. llvm-svn: 343787
* [llvm-mca] Check for inconsistencies when constructing instruction descriptors.Andrea Di Biagio2018-10-042-0/+7
| | | | | | | This should help with catching inconsistent definitions of instructions with zero opcodes, which also declare to consume scheduler/pipeline resources. llvm-svn: 343766
* [llvm-mca] Add support for move elimination in class RegisterFile.Andrea Di Biagio2018-10-033-10/+83
| | | | | | | | | | | | | | | | | | | This patch teaches class RegisterFile how to analyze register writes from instructions that are move elimination candidates. In particular, it teaches it how to check if a move can be effectively eliminated by the underlying PRF, and (if necessary) how to perform move elimination. The long term goal is to allow processor models to describe instructions that are valid move elimination candidates. The idea is to let register file definitions in tablegen declare if/when moves can be eliminated. This patch is a non functional change. The logic that performs move elimination is currently disabled. A future patch will add support for move elimination in the processor models, and enable this new code path. llvm-svn: 343691
* [llvm-mca] Remove unecessary forward decls. NFC.Matt Davis2018-10-024-5/+0
| | | | | | This patch also removes an unecessary include. llvm-svn: 343621
* [llvm-mca] Constify the 'notify' routines. NFC.Matt Davis2018-10-023-7/+7
| | | | | | Also fixed up some whitespace formatting in DispatchStage.cpp. llvm-svn: 343615
* [llvm-mca] Rename the 'Subtract' method to 'subtract'Matt Davis2018-10-011-1/+1
| | | | llvm-svn: 343549
* [llvm-mca] Teach how to track zero registers in class RegisterFile.Andrea Di Biagio2018-09-282-15/+44
| | | | | | | | | This change is in preparation for a future work on improving support for optimizable register moves. We already know if a write is from a zero-idiom, so we can propagate that bit of information to the PRF. We use an APInt mask to identify registers that are set to zero. llvm-svn: 343307
* [llvm-mca] Improve code comments in LSUnit.{h, cpp}. NFCAndrea Di Biagio2018-09-241-14/+14
| | | | llvm-svn: 342877
* [llvm-mca] Add the ability to mark register reads/writes associated with ↵Andrea Di Biagio2018-09-182-16/+23
| | | | | | | | | | | | | | | | | | dep-breaking instructions. NFCI This patch adds two new boolean fields: - Field `ReadState::IndependentFromDef`. - Field `WriteState::WritesZero`. Field `IndependentFromDef` is set for ReadState objects associated with dependency-breaking instructions. It is used by the simulator when updating data dependencies between registers. Field `WritesZero` is set by WriteState objects associated with dependency breaking zero-idiom instructions. It helps the PRF identify which writes don't consume any physical registers. llvm-svn: 342483
* [llvm-mca] Slightly refactor class InstRef. NFC.Andrea Di Biagio2018-09-181-9/+12
| | | | llvm-svn: 342480
* [llvm-mca] Delay calculation of Cycles per Resources, separate the cycles ↵Matt Davis2018-09-116-14/+57
| | | | | | | | | | | | | | | | | | | | | | | | | and resource quantities. Summary: This patch removes the storing of accumulated floating point data within the llvm-mca library. This patch splits-up the two quantities: cycles and number of resource units. By splitting-up these two quantities, we delay the calculation of "cycles per resource unit" until that value is read, reducing the chance of accumulating floating point error. I considered using the APFloat, but after measuring performance, for a large (many iteration) sample, I decided to go with this faster solution. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: llvm-commits, javed.absar, tschuett, gbedwell Differential Revision: https://reviews.llvm.org/D51903 llvm-svn: 341980
* [llvm-mca] Report the number of dispatched micro opcodes in the ↵Andrea Di Biagio2018-08-302-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DispatchStatistics view. This patch introduces the following changes to the DispatchStatistics view: * DispatchStatistics now reports the number of dispatched opcodes instead of the number of dispatched instructions. * The "Dynamic Dispatch Stall Cycles" table now also reports the percentage of stall cycles against the total simulated cycles. This change allows users to easily compare dispatch group sizes with the processor DispatchWidth. Before this change, it was difficult to correlate the two numbers, since DispatchStatistics view reported numbers of instructions (instead of opcodes). DispatchWidth defines the maximum size of a dispatch group in terms of number of micro opcodes. The other change introduced by this patch is related to how DispatchStage generates "instruction dispatch" events. In particular: * There can be multiple dispatch events associated with a same instruction * Each dispatch event now encapsulates the number of dispatched micro opcodes. The number of micro opcodes declared by an instruction may exceed the processor DispatchWidth. Therefore, we cannot assume that instructions are always fully dispatched in a single cycle. DispatchStage knows already how to handle instructions declaring a number of opcodes bigger that DispatchWidth. However, DispatchStage always emitted a single instruction dispatch event (during the first simulated dispatch cycle) for instructions dispatched. With this patch, DispatchStage now correctly notifies multiple dispatch events for instructions that cannot be dispatched in a single cycle. A few views had to be modified. Views can no longer assume that there can only be one dispatch event per instruction. Tests (and docs) have been updated. Differential Revision: https://reviews.llvm.org/D51430 llvm-svn: 341055
* [llvm-mca] Remove unused formal. NFC.Matt Davis2018-08-291-3/+2
| | | | llvm-svn: 340888
* [llvm-mca] use llvm::any_of instead of std::any_of. NFCAndrea Di Biagio2018-08-281-1/+2
| | | | llvm-svn: 340863
* [llvm-mca] Pass an instruction reference when notifying event listeners ↵Andrea Di Biagio2018-08-282-8/+7
| | | | | | about reserved/released buffer resources. NFC llvm-svn: 340821
* [llvm-mca] Introduce the llvm-mca library and organize the directory ↵Matt Davis2018-08-2719-0/+2377
accordingly. NFC. Summary: This patch introduces llvm-mca as a library. The driver (llvm-mca.cpp), views, and stats, are not part of the library. Those are separate components that are not required for the functioning of llvm-mca. The directory has been organized as follows: All library source files now reside in: - `lib/HardwareUnits/` - All subclasses of HardwareUnit (these represent the simulated hardware components of a backend). (LSUnit does not inherit from HardwareUnit, but Scheduler does which uses LSUnit). - `lib/Stages/` - All subclasses of the pipeline stages. - `lib/` - This is the root of the library and contains library code that does not fit into the Stages or HardwareUnit subdirs. All library header files now reside in the `include` directory and mimic the same layout as the `lib` directory mentioned above. In the (near) future we would like to move the library (include and lib) contents from tools and into the core of llvm somewhere. That change would allow various analysis and optimization passes to make use of MCA functionality for things like cost modeling. I left all of the non-library code just where it has always been, in the root of the llvm-mca directory. The include directives for the non-library source file have been updated to refer to the llvm-mca library headers. I updated the llvm-mca/CMakeLists.txt file to include the library headers, but I made the non-library code explicitly reference the library's 'include' directory. Once we eventually (hopefully) migrate the MCA library components into llvm the include directives used by the non-library source files will be updated to point to the proper location in llvm. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: mgorny, javed.absar, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D50929 llvm-svn: 340755
OpenPOWER on IntegriCloud