aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-mca/CodeRegionGenerator.h
AgeCommit message (Collapse)AuthorFilesLines
2023-07-06[llvm-mca][RISCV] vsetivli and vsetvli act as instrumentsMichael Maitland1-4/+73
Since the LMUL data that is needed to create an instrument is avaliable statically from vsetivli and vsetvli instructions, LMUL instruments can be automatically generated so that clients of the tool do no need to manually insert instrument comments. Instrument comments may be placed after a vset{i}vli instruction, which will override instrument that was automatically inserted. As a result, clients of llvm-mca instruments do not need to update their existing instrument comments. However, if the instrument has the same LMUL as the vset{i}vli, then it is reccomended to remove the instrument comment as it becomes redundant. Differential Revision: https://reviews.llvm.org/D154526
2023-06-03[llvm-mca] Modernize MCACommentConsumer (NFC)Kazu Hirata1-2/+2
2022-11-22[llvm-mca] Fix class dominance warnings for parseCodeRegionsMichael Maitland1-0/+10
Fixes issue [59091](https://github.com/llvm/llvm-project/issues/59091). `CodeRegionGenerator::parseCodeRegions` is implemented by `AsmCodeRegionGenerator`. If it were to be implemented in `AnalysisRegionGenerator` or `InstrumentRegionGenerator`, then `parseCodeRegions` from an `AsmAnalysisRegionGenerator` or `AsmInstrumentRegionGenerator` object would be ambiguous. To solve this, `AsmAnalysisRegionGenerator` and `AsmInstrumentRegionGenerator` qualify their call to `AsmCodeRegionGenerator::parseCodeRegions`. Differential Revision: https://reviews.llvm.org/D138462
2022-11-18[RISCV][llvm-mca] Use LMUL Instruments to provide more accurate reports on RISCVMichael Maitland1-14/+138
On x86 and AArch, SIMD instructions encode all of the scheduling information in the instruction itself. For example, VADD.I16 q0, q1, q2 is a neon instruction that operates on 16-bit integer elements stored in 128-bit Q registers, which leads to eight 16-bit lanes in parallel. This kind of information impacts how the instruction takes to execute and what dependencies this may cause. On RISCV however, the data that impacts scheduling is encoded in CSR registers such as vtype or vl, in addition with the instruction itself. But MCA does not track or use the data in these registers. This patch fixes this problem by introducing Instruments into MCA. * Replace `CodeRegions` with `AnalysisRegions` * Add `Instrument` and `InstrumentManager` * Add `InstrumentRegions` * Add RISCV Instrument and `InstrumentManager` * Parse `Instruments` in driver * Use instruments to override schedule class * RISCV use lmul instrument to override schedule class * Fix unit tests to pass empty instruments * Add -ignore-im clopt to disable this change A prior version of this patch was commited in 5e82ee537321. 2323a4ee610f reverted that change because the unit test files caused build errors. The change with fixes were committed in b88b8307bf9e but reverted once again e8e92c8313a0 due to more build errors. This commit adds the prior changes and fixes the build error. Differential Revision: https://reviews.llvm.org/D137440
2022-11-15Revert "[RISCV][llvm-mca] Use LMUL Instruments to provide more accurate ↵Michael Maitland1-138/+14
reports on RISCV" This reverts commit b88b8307bf9e24f53e7ef3052abf2c506ff55fd2.
2022-11-15[RISCV][llvm-mca] Use LMUL Instruments to provide more accurate reports on RISCVMichael Maitland1-14/+138
On x86 and AArch, SIMD instructions encode all of the scheduling information in the instruction itself. For example, VADD.I16 q0, q1, q2 is a neon instruction that operates on 16-bit integer elements stored in 128-bit Q registers, which leads to eight 16-bit lanes in parallel. This kind of information impacts how the instruction takes to execute and what dependencies this may cause. On RISCV however, the data that impacts scheduling is encoded in CSR registers such as vtype or vl, in addition with the instruction itself. But MCA does not track or use the data in these registers. This patch fixes this problem by introducing Instruments into MCA. * Replace `CodeRegions` with `AnalysisRegions` * Add `Instrument` and `InstrumentManager` * Add `InstrumentRegions` * Add RISCV Instrument and `InstrumentManager` * Parse `Instruments` in driver * Use instruments to override schedule class * RISCV use lmul instrument to override schedule class * Fix unit tests to pass empty instruments * Add -ignore-im clopt to disable this change A prior version of this patch was commited in. It was reverted in 5e82ee5373211db8522181054800ccd49461d9d8. 2323a4ee610f5e1db74d362af4c6fb8c704be8f6 reverted that change because the unit test files caused build errors. This commit adds the original changes and the fixed test files. Differential Revision: https://reviews.llvm.org/D137440
2022-11-15Revert "[RISCV][llvm-mca] Use LMUL Instruments to provide more accurate ↵Michael Maitland1-138/+14
reports on RISCV" This reverts commit 5e82ee5373211db8522181054800ccd49461d9d8.
2022-11-15[RISCV][llvm-mca] Use LMUL Instruments to provide more accurate reports on RISCVMichael Maitland1-14/+138
On x86 and AArch, SIMD instructions encode all of the scheduling information in the instruction itself. For example, VADD.I16 q0, q1, q2 is a neon instruction that operates on 16-bit integer elements stored in 128-bit Q registers, which leads to eight 16-bit lanes in parallel. This kind of information impacts how the instruction takes to execute and what dependencies this may cause. On RISCV however, the data that impacts scheduling is encoded in CSR registers such as vtype or vl, in addition with the instruction itself. But MCA does not track or use the data in these registers. This patch fixes this problem by introducing Instruments into MCA. * Replace `CodeRegions` with `AnalysisRegions` * Add `Instrument` and `InstrumentManager` * Add `InstrumentRegions` * Add RISCV Instrument and `InstrumentManager` * Parse `Instruments` in driver * Use instruments to override schedule class * RISCV use lmul instrument to override schedule class * Fix unit tests to pass empty instruments * Add -ignore-im clopt to disable this change Differential Revision: https://reviews.llvm.org/D137440
2021-10-08Move TargetRegistry.(h|cpp) from Support to MCReid Kleckner1-1/+1
This moves the registry higher in the LLVM library dependency stack. Every client of the target registry needs to link against MC anyway to actually use the target, so we might as well move this out of Support. This allows us to ensure that Support doesn't have includes from MC/*. Differential Revision: https://reviews.llvm.org/D111454
2021-07-28[MCA] Moving the target specific CustomBehaviour impl. from /tools/llvm-mca/ ↵Patrick Holland1-2/+2
to /lib/Target/. Differential Revision: https://reviews.llvm.org/D106775
2021-05-19[MCA] llvm-mca MCTargetStreamer segfault fixPatrick Holland1-2/+4
In order to create the code regions for llvm-mca to analyze, llvm-mca creates an AsmCodeRegionGenerator and calls AsmCodeRegionGenerator::parseCodeRegions(). Within this function, both an MCAsmParser and MCTargetAsmParser are created so that MCAsmParser::Run() can be used to create the code regions for us. These parser classes were created for llvm-mc so they are designed to emit code with an MCStreamer and MCTargetStreamer that are expected to be setup and passed into the MCAsmParser constructor. Because llvm-mca doesn’t want to emit any code, an MCStreamerWrapper class gets created instead and passed into the MCAsmParser constructor. This wrapper inherits from MCStreamer and overrides many of the emit methods to just do nothing. The exception is the emitInstruction() method which calls Regions.addInstruction(Inst). This works well and allows llvm-mca to utilize llvm-mc’s MCAsmParser to build our code regions, however there are a few directives which rely on the MCTargetStreamer. llvm-mc assumes that the MCStreamer that gets passed into the MCAsmParser’s constructor has a valid pointer to an MCTargetStreamer. Because llvm-mca doesn’t setup an MCTargetStreamer, when the parser encounters one of those directives, a segfault will occur. In x86, each one of these 7 directives will cause this segfault if they exist in the input assembly to llvm-mca: .cv_fpo_proc .cv_fpo_setframe .cv_fpo_pushreg .cv_fpo_stackalloc .cv_fpo_stackalign .cv_fpo_endprologue .cv_fpo_endproc I haven’t looked at other targets, but I wouldn’t be surprised if some of the other ones also have certain directives which could result in this same segfault. My proposed solution is to simply initialize an MCTargetStreamer after we initialize the MCStreamerWrapper. The MCTargetStreamer requires an ostream object, but we don’t actually want any of these directives to be emitted anywhere, so I use an ostream created with the nulls() function. Since this needs to happen after the MCStreamerWrapper has been initialized, it needs to happen within the AsmCodeRegionGenerator::parseCodeRegions() function. The MCTargetStreamer also needs an MCInstPrinter which is easiest to initialize within the main() function of llvm-mca. So this MCInstPrinter gets constructed within main() then passed into the parseCodeRegions() function as a parameter. (If you feel like it would be appropriate and possible to create the MCInstPrinter within the parseCodeRegions() function, then feel free to modify my solution. That would stop us from having to pass it into the function and would limit its scope / lifetime.) My solution stops the segfault from happening and still passes all of the current (expected) llvm-mca tests. I also added a new test for x86 that checks for this segfault on an input that includes one of the .cv_fpo directives (this test fails without my solution, but passes with it). As far as I can tell, all of the functions that I modified are only called from within llvm-mca so there shouldn’t be any worries about breaking other tools. Differential Revision: https://reviews.llvm.org/D102709
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-11-07[llvm-mca] Move the AssembleInput logic into its own class.Matt Davis1-0/+70
Summary: This patch introduces a CodeRegionGenerator class which is responsible for parsing some type of input and creating a 'CodeRegions' instance for use by llvm-mca. In the future, we will also have a CodeRegionGenerator subclass for converting an input object file into CodeRegions. For now, we only have the subclass for converting input assembly into CodeRegions. This is mostly a NFC patch, as the logic remains close to the original, but now encapsulated in its own class and moved outside of llvm-mca.cpp. Reviewers: andreadb, courbet, RKSimon Reviewed By: andreadb Subscribers: mgorny, tschuett, gbedwell, llvm-commits Differential Revision: https://reviews.llvm.org/D54179 llvm-svn: 346344