summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-mca/lib/HardwareUnits/RegisterFile.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-mca] Fix an invalid memory read introduced by r346487.Andrea Di Biagio2018-11-221-3/+3
| | | | | | | | | | | | | | | | | | | | 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] Add extra counters for move elimination in view ↵Andrea Di Biagio2018-11-011-12/+32
| | | | | | | | | | | | | | | | | | 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] Move namespace mca inside llvm::Fangrui Song2018-10-301-2/+2
| | | | | | | | | | | | | | | | 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] Correctly set aliases for register writes introduced by optimized ↵Andrea Di Biagio2018-10-121-11/+54
| | | | | | | | | | | 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
* [tblgen][llvm-mca] Add the ability to describe move elimination candidates ↵Andrea Di Biagio2018-10-121-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | via tablegen. This patch adds the ability to identify instructions that are "move elimination candidates". It also allows scheduling models to describe processor register files that allow move elimination. A move elimination candidate is an instruction that can be eliminated at register renaming stage. Each subtarget can specify which instructions are move elimination candidates with the help of tablegen class "IsOptimizableRegisterMove" (see llvm/Target/TargetInstrPredicate.td). For example, on X86, BtVer2 allows both GPR and MMX/SSE moves to be eliminated. The definition of 'IsOptimizableRegisterMove' for BtVer2 looks like this: ``` def : IsOptimizableRegisterMove<[ InstructionEquivalenceClass<[ // GPR variants. MOV32rr, MOV64rr, // MMX variants. MMX_MOVQ64rr, // SSE variants. MOVAPSrr, MOVUPSrr, MOVAPDrr, MOVUPDrr, MOVDQArr, MOVDQUrr, // AVX variants. VMOVAPSrr, VMOVUPSrr, VMOVAPDrr, VMOVUPDrr, VMOVDQArr, VMOVDQUrr ], CheckNot<CheckSameRegOperand<0, 1>> > ]>; ``` Definitions of IsOptimizableRegisterMove from processor models of a same Target are processed by the SubtargetEmitter to auto-generate a target-specific override for each of the following predicate methods: ``` bool TargetSubtargetInfo::isOptimizableRegisterMove(const MachineInstr *MI) const; bool MCInstrAnalysis::isOptimizableRegisterMove(const MCInst &MI, unsigned CPUID) const; ``` By default, those methods return false (i.e. conservatively assume that there are no move elimination candidates). Tablegen class RegisterFile has been extended with the following information: - The set of register classes that allow move elimination. - Maxium number of moves that can be eliminated every cycle. - Whether move elimination is restricted to moves from registers that are known to be zero. This patch is structured in three part: A first part (which is mostly boilerplate) adds the new 'isOptimizableRegisterMove' target hooks, and extends existing register file descriptors in MC by introducing new fields to describe properties related to move elimination. A second part, uses the new tablegen constructs to describe move elimination in the BtVer2 scheduling model. A third part, teaches llm-mca how to query the new 'isOptimizableRegisterMove' hook to mark instructions that are candidates for move elimination. It also teaches class RegisterFile how to describe constraints on move elimination at PRF granularity. llvm-mca tests for btver2 show differences before/after this patch. Differential Revision: https://reviews.llvm.org/D53134 llvm-svn: 344334
* [tblgen][CodeGenSchedule] Add a check for invalid RegisterFile definitions ↵Andrea Di Biagio2018-10-111-6/+4
| | | | | | with zero physical registers. llvm-svn: 344235
* [llvm-mca] Minor refactoring in preparation for a patch that will fully fix ↵Andrea Di Biagio2018-10-101-7/+9
| | | | | | PR36671. NFCI llvm-svn: 344149
* [llvm-mca] Move field 'AllowZeroMoveEliminationOnly' to class RegisterFile. NFC.Andrea Di Biagio2018-10-041-1/+19
| | | | | | | | | | | | | | | | 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] Add support for move elimination in class RegisterFile.Andrea Di Biagio2018-10-031-0/+36
| | | | | | | | | | | | | | | | | | | 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 redundant namespace prefixes. NFCAndrea Di Biagio2018-09-281-3/+3
| | | | | | We are already "using" namespace llvm in all the files modified by this change. llvm-svn: 343312
* [llvm-mca] Teach how to track zero registers in class RegisterFile.Andrea Di Biagio2018-09-281-11/+34
| | | | | | | | | 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::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-271-4/+3
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D52573 llvm-svn: 343163
* [llvm-mca] Add the ability to mark register reads/writes associated with ↵Andrea Di Biagio2018-09-181-5/+5
| | | | | | | | | | | | | | | | | | 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] Fix typo in debug output. NFC.Matt Davis2018-09-011-1/+1
| | | | llvm-svn: 341281
* [llvm-mca] Introduce the llvm-mca library and organize the directory ↵Matt Davis2018-08-271-0/+350
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