summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-mca/InstrBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [llvm-mca] Introduce the llvm-mca library and organize the directory ↵Matt Davis2018-08-271-485/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [llvm-mca] Propagate fatal llvm-mca errors from library classes to driver.Matt Davis2018-08-131-28/+44
| | | | | | | | | | | | | | | | | Summary: This patch introduces error handling to propagate the errors from llvm-mca library classes (or what will become library classes) up to the driver. This patch also introduces an enum to make clearer the intention of the return value for Stage::execute. This supports PR38101. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: llvm-commits, tschuett, gbedwell Differential Revision: https://reviews.llvm.org/D50561 llvm-svn: 339594
* [llvm-mca][BtVer2] Teach how to identify dependency-breaking idioms.Andrea Di Biagio2018-07-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch teaches llvm-mca how to identify dependency breaking instructions on btver2. An example of dependency breaking instructions is the zero-idiom XOR (example: `XOR %eax, %eax`), which always generates zero regardless of the actual value of the input register operands. Dependency breaking instructions don't have to wait on their input register operands before executing. This is because the computation is not dependent on the inputs. Not all dependency breaking idioms are also zero-latency instructions. For example, `CMPEQ %xmm1, %xmm1` is independent on the value of XMM1, and it generates a vector of all-ones. That instruction is not eliminated at register renaming stage, and its opcode is issued to a pipeline for execution. So, the latency is not zero. This patch adds a new method named isDependencyBreaking() to the MCInstrAnalysis interface. That method takes as input an instruction (i.e. MCInst) and a MCSubtargetInfo. The default implementation of isDependencyBreaking() conservatively returns false for all instructions. Targets may override the default behavior for specific CPUs, and return a value which better matches the subtarget behavior. In future, we should teach to Tablegen how to automatically generate the body of isDependencyBreaking from scheduling predicate definitions. This would allow us to expose the knowledge about dependency breaking instructions to the machine schedulers (and, potentially, other codegen passes). Differential Revision: https://reviews.llvm.org/D49310 llvm-svn: 338372
* [llvm-mca] Improve a few debug prints. NFCAndrea Di Biagio2018-07-131-8/+12
| | | | llvm-svn: 337003
* [llvm-mca] report an error if the assembly sequence contains an unsupported ↵Andrea Di Biagio2018-07-091-22/+36
| | | | | | | | | | | | | instruction. This is a short-term fix for PR38093. For now, we llvm::report_fatal_error if the instruction builder finds an unsupported instruction in the instruction stream. We need to revisit this fix once we start addressing PR38101. Essentially, we need a better framework for error handling. llvm-svn: 336543
* [llvm-mca] A write latency cannot be a negative value. NFCAndrea Di Biagio2018-07-061-2/+4
| | | | llvm-svn: 336437
* [llvm-mca] Remove field HasReadAdvanceEntries from class ReadDescriptor.Andrea Di Biagio2018-06-291-4/+0
| | | | | | | | | | | | This simplifies the logic that updates RAW dependencies in the DispatchStage. There is no advantage in storing that flag in the ReadDescriptor; we should simply rely on the call to `STI.getReadAdvanceCycles()` to obtain the ReadAdvance cycles. If there are no read-advance entries, then method `getReadAdvanceCycles()` quickly returns 0. No functional change intended. llvm-svn: 335977
* [llvm-mca] Set the operand ID for implicit register reads/writes. NFCAndrea Di Biagio2018-06-221-4/+4
| | | | | | | Also, move the definition of InstRef at the end of Instruction.h to avoid a forward declaration. llvm-svn: 335363
* [llvm-mca] Updates comment in code, and remove some stale comments. NFCAndrea Di Biagio2018-06-211-57/+1
| | | | | | | Also, rename fields `TotalMappings` and `NumUsedMappings` in struct RegisterMappingTracker into `NumPhysRegs` and `NumUsedPhysRegs`. llvm-svn: 335219
* [llvm-mca] use APint::operator[] to obtain the bit value. NFCAndrea Di Biagio2018-06-201-4/+2
| | | | llvm-svn: 335131
* [llvm-mca][X86] Teach how to identify register writes that implicitly clear ↵Andrea Di Biagio2018-06-201-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the upper portion of a super-register. This patch teaches llvm-mca how to identify register writes that implicitly zero the upper portion of a super-register. On X86-64, a general purpose register is implemented in hardware as a 64-bit register. Quoting the Intel 64 Software Developer's Manual: "an update to the lower 32 bits of a 64 bit integer register is architecturally defined to zero extend the upper 32 bits". Also, a write to an XMM register performed by an AVX instruction implicitly zeroes the upper 128 bits of the aliasing YMM register. This patch adds a new method named clearsSuperRegisters to the MCInstrAnalysis interface to help identify instructions that implicitly clear the upper portion of a super-register. The rest of the patch teaches llvm-mca how to use that new method to obtain the information, and update the register dependencies accordingly. I compared the kernels from tests clear-super-register-1.s and clear-super-register-2.s against the output from perf on btver2. Previously there was a large discrepancy between the estimated IPC and the measured IPC. Now the differences are mostly in the noise. Differential Revision: https://reviews.llvm.org/D48225 llvm-svn: 335113
* [RFC][patch 3/3] Add support for variant scheduling classes in llvm-mca.Andrea Di Biagio2018-06-041-13/+27
| | | | | | | | | | | | | | | | | | | | | | | | This patch is the last of a sequence of three patches related to LLVM-dev RFC "MC support for variant scheduling classes". http://lists.llvm.org/pipermail/llvm-dev/2018-May/123181.html This fixes PR36672. The main goal of this patch is to teach llvm-mca how to solve variant scheduling classes. This patch does that, plus it adds new variant scheduling classes to the BtVer2 scheduling model to identify so-called zero-idioms (i.e. so-called dependency breaking instructions that are known to generate zero, and that are optimized out in hardware at register renaming stage). Without the BtVer2 change, this patch would not have had any meaningful tests. This patch is effectively the union of two changes: 1) a change that teaches llvm-mca how to resolve variant scheduling classes. 2) a change to the BtVer2 scheduling model that allows us to special-case packed XOR zero-idioms (this partially fixes PR36671). Differential Revision: https://reviews.llvm.org/D47374 llvm-svn: 333909
* [llvm-mca] Track cycles contributed by resources that are in a 'Super' ↵Andrea Di Biagio2018-06-041-1/+19
| | | | | | | | | | | | | | relationship. This is required if we want to correctly match the behavior of method SubtargetEmitter::ExpandProcResource() in Tablegen. When computing the set of "consumed" processor resources and resource cycles, the logic in ExpandProcResource() doesn't update the number of resource cycles contributed by a "Super" resource to a group. We need to take this into account when a model declares a processor resource which is part of a 'processor resource group', and it is also used as the "Super" of other resources. llvm-svn: 333892
* Rename DEBUG macro to LLVM_DEBUG.Nicola Zaghen2018-05-141-11/+11
| | | | | | | | | | | | | | | | 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] use colors for warnings and notes generated by InstrBuilder.Andrea Di Biagio2018-05-041-8/+9
| | | | llvm-svn: 331517
* [llvm-mca] remove unused argument from method InstrBuilder::createInstrDescImpl.Andrea Di Biagio2018-05-041-5/+6
| | | | | | | | | 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] Remove method Instruction::isZeroLatency(). NFCIAndrea Di Biagio2018-04-251-4/+3
| | | | llvm-svn: 330807
* [llvm-mca] Do not assume that implicit reads cannot be associated with ↵Andrea Di Biagio2018-04-021-4/+14
| | | | | | | | | | ReadAdvance entries. Before, the instruction builder incorrectly assumed that only explicit reads could have been associated with ReadAdvance entries. This patch fixes the issue and adds a test to verify it. llvm-svn: 328972
* [tools] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-011-10/+10
| | | | | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: JDevlieghere, zturner, echristo, dberris, friss Reviewed By: echristo Subscribers: gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D45141 llvm-svn: 328943
* [llvm-mca] Correctly set the ReadAdvance information for register use operands.Andrea Di Biagio2018-03-291-0/+2
| | | | | | | | | | | | The tool was passing the wrong operand index to method MCSubtargetInfo::getReadAdvanceCycles(). That method requires a "UseIdx", and not the operand index. This was found when testing X86 code where instructions had a memory folded operand. This patch fixes the issue and adds test read-advance-1.s to ensure that the ReadAfterLd (a ReadAdvance of 3cy) information is correctly used. llvm-svn: 328790
* [llvm-mca] run clang-format on all files.Andrea Di Biagio2018-03-241-4/+4
| | | | | | This also addresses Simon's review comment in D44839. llvm-svn: 328428
* [llvm-mca] Simplify code. NFCAndrea Di Biagio2018-03-221-6/+4
| | | | llvm-svn: 328187
* [llvm-mca] Remove const from a bunch of ArrayRef. NFCAndrea Di Biagio2018-03-201-1/+1
| | | | llvm-svn: 328018
* [llvm-mca] Use llvm::make_unique in a few places. NFCAndrea Di Biagio2018-03-201-17/+13
| | | | | | 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-9/+6
| | | | | | | | | | | | | | | | | | 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] Remove unused variable from InstrBuilder.cpp. NFCAndrea Di Biagio2018-03-141-1/+0
| | | | | | This was causing a buildbot failure. llvm-svn: 327517
* [llvm-mca] Move the logic that updates the register files from InstrBuilder ↵Andrea Di Biagio2018-03-141-33/+3
| | | | | | | | | | | | | | | | | | | 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] Simplify code that computes the latency of an instruction inAndrea Di Biagio2018-03-131-30/+5
| | | | | | | | | InstrBuilder. NFCI This was possible because of r327406, which added function`computeInstrLatency` to MCSchedModel. llvm-svn: 327415
* [llvm-mca] LLVM Machine Code Analyzer.Andrea Di Biagio2018-03-081-0/+525
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