Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3 |
|
#
baf77036 |
| 07-Aug-2024 |
Chinmay Deshpande <cddeshpa@uci.edu> |
`InOrderIssueStage` for llvm-mca should be generic over LSUnitBase (#101534)
Other HardwareUnits (such as the
[Scheduler](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/MCA/Hardwa
`InOrderIssueStage` for llvm-mca should be generic over LSUnitBase (#101534)
Other HardwareUnits (such as the
[Scheduler](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/MCA/HardwareUnits/Scheduler.h#L71))
and Stages (such as
[RetireStage](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/MCA/Stages/RetireStage.h#L32))
are generic over `LSUnitBase` rather than the specialized `LSUnit`.
show more ...
|
Revision tags: llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
a6ee0adb |
| 06-Mar-2024 |
Michael Maitland <michaeltmaitland@gmail.com> |
[llvm-mca][AMDGPU] Retire instructions that have issue carry over correctly (#83881)
https://github.com/llvm/llvm-project/issues/83775 shows llvm-mca hits
sanitizer error in cycleEnd. There was an
[llvm-mca][AMDGPU] Retire instructions that have issue carry over correctly (#83881)
https://github.com/llvm/llvm-project/issues/83775 shows llvm-mca hits
sanitizer error in cycleEnd. There was an instruction that takes
multiple cycles to issue and is finished executing directly after issue.
Prior to this patch, the instruction is retired on the first issue
cycle, despite taking multiple cycles to issue.
To fix this, if an instruction takes multiple cycles to issue and is
done executing after issue, let updateCarriedOver retire the instruction
when it is fully issued.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0 |
|
#
55cedf9c |
| 12-Mar-2022 |
Patrick Holland <patrickeholland@gmail.com> |
[MCA] Moved six instruction flags from InstrDesc to InstructionBase.
Differential Revision: https://reviews.llvm.org/D121508
|
Revision tags: llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
b932bdf5 |
| 08-Jan-2022 |
Kazu Hirata <kazu@google.com> |
[llvm] Remove redundant member initialization (NFC)
Identified with readability-redundant-member-init.
|
#
e5947760 |
| 03-Jan-2022 |
Kazu Hirata <kazu@google.com> |
Revert "[llvm] Remove redundant member initialization (NFC)"
This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.
This patch causes gcc to issue a lot of warnings like:
warning: base cl
Revert "[llvm] Remove redundant member initialization (NFC)"
This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.
This patch causes gcc to issue a lot of warnings like:
warning: base class ‘class llvm::MCParsedAsmOperand’ should be explicitly initialized in the copy constructor [-Wextra]
show more ...
|
#
fd480888 |
| 02-Jan-2022 |
Kazu Hirata <kazu@google.com> |
[llvm] Remove redundant member initialization (NFC)
Identified with readability-redundant-member-init.
|
Revision tags: llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
#
3b3c0134 |
| 20-Aug-2021 |
Patrick Holland <patrickeholland@gmail.com> |
[MCA] Fixing bug that was causing LSUnit not to realize an instruction finished executing when the instruction has 0 latency.
Differential Revision: https://reviews.llvm.org/D108443
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
#
bcc83a2e |
| 09-Jun-2021 |
Andrew Savonichev <andrew.savonichev@gmail.com> |
[MCA] Use LSU for the in-order pipeline
Load/Store unit is used to enforce order of loads and stores if they alias (controlled by --noalias=false option).
Fixes PR50483 - [MCA] In-order pipeline do
[MCA] Use LSU for the in-order pipeline
Load/Store unit is used to enforce order of loads and stores if they alias (controlled by --noalias=false option).
Fixes PR50483 - [MCA] In-order pipeline doesn't track memory load/store dependencies.
Differential Revision: https://reviews.llvm.org/D103955
show more ...
|
#
d0373645 |
| 21-Jun-2021 |
Patrick Holland <patrickeholland@gmail.com> |
[MCA] [In-order pipeline] Fix for 0 latency instruction causing assertion to fail.
0 latency instructions now get processed and retired properly within the in-order pipeline. Had to fix a bug within
[MCA] [In-order pipeline] Fix for 0 latency instruction causing assertion to fail.
0 latency instructions now get processed and retired properly within the in-order pipeline. Had to fix a bug within TimelineView.cpp as well that would show up when a 0 latency instruction was the first instruction in the source.
Differential Revision: https://reviews.llvm.org/D104675
show more ...
|
#
ef16c8ea |
| 16-Jun-2021 |
Patrick Holland <patrickeholland@gmail.com> |
Reapply "[MCA] Adding the CustomBehaviour class to llvm-mca".
The original change was pushed in main as commit f7a23ecece52. It was then reverted by commit a04f01bab2 because it caused linker failur
Reapply "[MCA] Adding the CustomBehaviour class to llvm-mca".
The original change was pushed in main as commit f7a23ecece52. It was then reverted by commit a04f01bab2 because it caused linker failures on buildbots that don't build the AMDGPU target.
--
Some instructions are not defined well enough within the target’s scheduling model for llvm-mca to be able to properly simulate its behaviour. The ideal solution to this situation is to modify the scheduling model, but that’s not always a viable strategy. Maybe other parts of the backend depend on that instruction being modelled the way that it is. Or maybe the instruction is quite complex and it’s difficult to fully capture its behaviour with tablegen. The CustomBehaviour class (which I will refer to as CB frequently) is designed to provide intuitive scaffolding for developers to implement the correct modelling for these instructions.
More details are available in the original commit log message (f7a23ecece52).
Differential Revision: https://reviews.llvm.org/D104149
show more ...
|
#
a04f01ba |
| 15-Jun-2021 |
Andrea Di Biagio <andrea.dibiagio@sony.com> |
Revert "[MCA] Adding the CustomBehaviour class to llvm-mca"
This reverts commit f7a23ecece524564a0c3e09787142cc6061027bb.
It appears to breaks buildbots that don't build the AMDGPU backend.
|
#
f7a23ece |
| 15-Jun-2021 |
Patrick Holland <patrickeholland@gmail.com> |
[MCA] Adding the CustomBehaviour class to llvm-mca
Some instructions are not defined well enough within the target’s scheduling model for llvm-mca to be able to properly simulate its behaviour. The
[MCA] Adding the CustomBehaviour class to llvm-mca
Some instructions are not defined well enough within the target’s scheduling model for llvm-mca to be able to properly simulate its behaviour. The ideal solution to this situation is to modify the scheduling model, but that’s not always a viable strategy. Maybe other parts of the backend depend on that instruction being modelled the way that it is. Or maybe the instruction is quite complex and it’s difficult to fully capture its behaviour with tablegen. The CustomBehaviour class (which I will refer to as CB frequently) is designed to provide intuitive scaffolding for developers to implement the correct modelling for these instructions.
Implementation details:
llvm-mca does its best to extract relevant register, resource, and memory information from every MCInst when lowering them to an mca::Instruction. It then uses this information to detect dependencies and simulate stalls within the pipeline. For some instructions, the information that gets captured within the mca::Instruction is not enough for mca to simulate them properly. In these cases, there are two main possibilities:
1. The instruction has a dependency that isn’t detected by mca. 2. mca is incorrectly enforcing a dependency that shouldn’t exist.
For the rest of this discussion, I will be focusing on (1), but I have put some thought into (2) and I may revisit it in the future.
So we have an instruction that has dependencies that aren’t picked up by mca. The basic idea for both pipelines in mca is that when an instruction wants to be dispatched, we first check for register hazards and then we check for resource hazards. This is where CB is injected. If no register or resource hazards have been detected, we make a call to CustomBehaviour::checkCustomHazard() to give the target specific CB the chance to detect and enforce any custom dependencies.
The return value for checkCustomHazaard() is an unsigned int representing the (minimum) number of cycles that the instruction needs to stall for. It’s fine to underestimate this value because when StallCycles gets down to 0, we’ll end up checking for all the hazards again before the instruction is actually dispatched. However, it’s important not to overestimate the value and the more accurate your estimate is, the more efficient mca’s execution can be.
In general, for checkCustomHazard() to be able to detect these custom dependencies, it needs information about the current instruction and also all of the instructions that are still executing within the pipeline. The mca pipeline uses mca::Instruction rather than MCInst and the current information encoded within each mca::Instruction isn’t sufficient for my use cases. I had to add a few extra attributes to the mca::Instruction class and have them get set by the MCInst during instruction building. For example, the current mca::Instruction doesn’t know its opcode, and it also doesn’t know anything about its immediate operands (both of which I had to add to the class).
With information about the current instruction, a list of all currently executing instructions, and some target specific objects (MCSubtargetInfo and MCInstrInfo which the base CB class has references to), developers should be able to detect and enforce most custom dependencies within checkCustomHazard. If you need more information than is present in the mca::Instruction, feel free to add attributes to that class and have them set during the lowering sequence from MCInst.
Fortunately, in the in-order pipeline, it’s very convenient for us to pass these arguments to checkCustomHazard. The hazard checking is taken care of within InOrderIssueStage::canExecute(). This function takes a const InstRef as a parameter (representing the instruction that currently wants to be dispatched) and the InOrderIssueStage class maintains a SmallVector<InstRef, 4> which holds all of the currently executing instructions. For the out-of-order pipeline, it’s a bit trickier to get the list of executing instructions and this is why I have held off on implementing it myself. This is the main topic I will bring up when I eventually make a post to discuss and ask for feedback.
CB is a base class where targets implement their own derived classes. If a target specific CB does not exist (or we pass in the -disable-cb flag), the base class is used. This base class trivially returns 0 from its checkCustomHazard() implementation (meaning that the current instruction needs to stall for 0 cycles aka no hazard is detected). For this reason, targets or users who choose not to use CB shouldn’t see any negative impacts to accuracy or performance (in comparison to pre-patch llvm-mca).
Differential Revision: https://reviews.llvm.org/D104149
show more ...
|
#
57646d38 |
| 27-May-2021 |
Andrea Di Biagio <andrea.dibiagio@sony.com> |
[MCA] Minor changes to the InOrderIssueStage. NFC
The constructor of InOrderIssueStage no longer takes as input a reference to the target scheduling model. The stage can always query the subtarget t
[MCA] Minor changes to the InOrderIssueStage. NFC
The constructor of InOrderIssueStage no longer takes as input a reference to the target scheduling model. The stage can always query the subtarget to obtain a reference to the scheduling model. The ResourceManager is no longer stored internally as a unique_ptr. Moved a couple of method definitions to the .cpp file.
show more ...
|
#
50770d8d |
| 27-May-2021 |
Andrea Di Biagio <andrea.dibiagio@sony.com> |
[MCA] Refactor the InOrderIssueStage stage. NFCI
Moved the logic that checks for RAW hazards from the InOrderIssueStage to the RegisterFile.
Changed how the InOrderIssueStage keeps track of backend
[MCA] Refactor the InOrderIssueStage stage. NFCI
Moved the logic that checks for RAW hazards from the InOrderIssueStage to the RegisterFile.
Changed how the InOrderIssueStage keeps track of backend stalls. Stall events are now generated from method notifyStallEvent().
No functional change intended.
show more ...
|
#
63cc9fd5 |
| 26-May-2021 |
Andrea Di Biagio <andrea.dibiagio@sony.com> |
[MCA][InOrderIssueStage] Fix LastWriteBackCycle computation.
Conservatively use the instruction latency to compute the last write-back cycle. Before this patch, the last write cycle computation was
[MCA][InOrderIssueStage] Fix LastWriteBackCycle computation.
Conservatively use the instruction latency to compute the last write-back cycle. Before this patch, the last write cycle computation was incorrect for store instructions that didn't declare any register writes.
show more ...
|
Revision tags: llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
bba25a9c |
| 24-Mar-2021 |
Andrew Savonichev <andrew.savonichev@gmail.com> |
[MCA] Support carry-over instructions for in-order processors
Instructions that have more uops than the processor's IssueWidth are issued in multiple cycles.
The patch fixes PR49712.
Differential
[MCA] Support carry-over instructions for in-order processors
Instructions that have more uops than the processor's IssueWidth are issued in multiple cycles.
The patch fixes PR49712.
Differential Revision: https://reviews.llvm.org/D99339
show more ...
|
#
292da93d |
| 14-Mar-2021 |
Andrew Savonichev <andrew.savonichev@gmail.com> |
[MCA] Disable RCU for InOrderIssueStage
This is a follow-up for: D98604 [MCA] Ensure that writes occur in-order
When instructions are aligned by the order of writes, they retire in-order naturally.
[MCA] Disable RCU for InOrderIssueStage
This is a follow-up for: D98604 [MCA] Ensure that writes occur in-order
When instructions are aligned by the order of writes, they retire in-order naturally. There is no need for an RCU, so it is disabled.
Differential Revision: https://reviews.llvm.org/D98628
show more ...
|
#
f5bdc88e |
| 23-Mar-2021 |
Andrea Di Biagio <andrea.dibiagio@sony.com> |
[MCA] Improved handling of negative read-advance cycles.
Before this patch, register writes were always invalidated by the RegisterFile at instruction commit stage. So, the RegisterFile was often lo
[MCA] Improved handling of negative read-advance cycles.
Before this patch, register writes were always invalidated by the RegisterFile at instruction commit stage. So, the RegisterFile was often losing the knowledge about the `execute cycle` of writes already committed. While this was not problematic for non-delayed reads, this was sometimes leading to inaccurate read latency computations in the presence of negative read-advance cycles.
This patch fixes the issue by changing how the RegisterFile component internally keeps track of the `execute cycle` information of each write. On every instruction executed, the RegisterFile gets notified by the RetireStage, so that it can internally record the execute cycle of each executed write. The `execute cycle` information is stored within WriteRef itself, and it is not invalidated when the write is committed.
show more ...
|
#
e6ce0db3 |
| 12-Mar-2021 |
Andrew Savonichev <andrew.savonichev@gmail.com> |
[MCA] Ensure that writes occur in-order
Delay the issue of a new instruction if that leads to out-of-order commits of writes.
This patch fixes the problem described in: https://bugs.llvm.org/show_b
[MCA] Ensure that writes occur in-order
Delay the issue of a new instruction if that leads to out-of-order commits of writes.
This patch fixes the problem described in: https://bugs.llvm.org/show_bug.cgi?id=41796#c3
Differential Revision: https://reviews.llvm.org/D98604
show more ...
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
#
d791695c |
| 29-Dec-2020 |
Andrew Savonichev <andrew.savonichev@gmail.com> |
[MCA] Add support for in-order CPUs
This patch adds a pipeline to support in-order CPUs such as ARM Cortex-A55.
In-order pipeline implements a simplified version of Dispatch, Scheduler and Execute
[MCA] Add support for in-order CPUs
This patch adds a pipeline to support in-order CPUs such as ARM Cortex-A55.
In-order pipeline implements a simplified version of Dispatch, Scheduler and Execute stages as a single stage. Entry and Retire stages are common for both in-order and out-of-order pipelines.
Differential Revision: https://reviews.llvm.org/D94928
show more ...
|