-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[CodeGen] Preserved additional analyses in StackSlotColoring pass. #93779
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CodeGen] Preserved additional analyses in StackSlotColoring pass. #93779
Conversation
Thank you for submitting a Pull Request (PR) to the LLVM Project! This PR will be automatically labeled and the relevant teams will be If you wish to, you can add reviewers by using the "Reviewers" section on this page. If this is not working for you, it is probably because you do not have write If you have received no comments on your PR for a week, you can request a review If you have further questions, they may be answered by the LLVM GitHub User Guide. You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums. |
✅ With the latest revision this PR passed the C/C++ code formatter. |
6ea80f6
to
dc21436
Compare
The pass pipeline of some architecture splits register allocation phase based on different register classes. As some analyses need to be computed at the beginning of the register allocation and kept alive till all values are assigned to some physical registers. This poses challenge with objective of introducing StackSlotColoring after partial virtual registers are assigned to physical registers, in order to optimize stack slots usage.As this pass doesn't preserve few analysis yet to be needed by the register allocation of the remaining virtual registers, necessiating them to be kept preserved.
Don't merge this patch now. Wait for the other patch to get approved. |
But, the other patch depends upon this. Unless this changes are not present there, many of the existing test cases would fail there, including the one I added. So it won't get approved. |
Did anymore change or any wait is needed (maybe because of dependency on other patch) to merge this PR. |
Don't see a reason to wait on that, this is fine standalone |
@@ -13,6 +13,7 @@ | |||
#include "llvm/ADT/BitVector.h" | |||
#include "llvm/ADT/SmallVector.h" | |||
#include "llvm/ADT/Statistic.h" | |||
#include "llvm/CodeGen/LiveDebugVariables.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could probably avoid the include by using the PassID
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For that, "char &llvm::passID = pass::ID", need to be added in the respective pass (not presently there in LiveDebugVariables.cpp), followed by exposing it via extern in Passes.h. So, I think this is better option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But those should be there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I was going through the Codegen passes, while most of them have it, others don't. What should be the right practice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They all should (but the PassID will go away in new PM so it's probably not worth fixing all of the missing instances)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, what should be supposed to be my final take on it!
// split into multiple phases based on register class. So, this pass | ||
// may be invoked multiple times requiring it to save these analyses to be | ||
// used by RA later. | ||
AU.addPreserved<LiveIntervals>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need to addPreserved<SlotIndexes>
? I'm also surprised you don't need to refer to LiveIntervals to maintain them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"addPreserved < SlotIndexes > " was already there before. As for LiveIntervals, it would be needed to be preserved for maybe the upcoming regAlloc pass for remaining register classes, else it is being re-computed, which somehow creating problem.
@llvm/pr-subscribers-llvm-regalloc Author: Vikash Gupta (vg0204) ChangesThe pass pipeline of some architecture splits register allocation phase based on different register classes. As some analyses need to be computed at the beginning of the register allocation and kept alive till all values are assigned to some physical registers. This poses challenge with objective of introducing StackSlotColoring after partial virtual registers are assigned to physical registers, in order to optimize stack slots usage.As this pass doesn't preserve few analysis yet to be needed by the register allocation of the remaining virtual registers, necessiating them to be kept preserved. Full diff: https://github.com/llvm/llvm-project/pull/93779.diff 1 Files Affected:
diff --git a/llvm/lib/CodeGen/StackSlotColoring.cpp b/llvm/lib/CodeGen/StackSlotColoring.cpp
index 9fdc8a338b52a..eb7d730e236bf 100644
--- a/llvm/lib/CodeGen/StackSlotColoring.cpp
+++ b/llvm/lib/CodeGen/StackSlotColoring.cpp
@@ -13,6 +13,7 @@
#include "llvm/ADT/BitVector.h"
#include "llvm/ADT/SmallVector.h"
#include "llvm/ADT/Statistic.h"
+#include "llvm/CodeGen/LiveDebugVariables.h"
#include "llvm/CodeGen/LiveInterval.h"
#include "llvm/CodeGen/LiveIntervalUnion.h"
#include "llvm/CodeGen/LiveIntervals.h"
@@ -64,6 +65,7 @@ namespace {
MachineFrameInfo *MFI = nullptr;
const TargetInstrInfo *TII = nullptr;
const MachineBlockFrequencyInfo *MBFI = nullptr;
+ SlotIndexes *Indexes = nullptr;
// SSIntervals - Spill slot intervals.
std::vector<LiveInterval*> SSIntervals;
@@ -152,6 +154,14 @@ namespace {
AU.addRequired<MachineBlockFrequencyInfo>();
AU.addPreserved<MachineBlockFrequencyInfo>();
AU.addPreservedID(MachineDominatorsID);
+
+ // In some Target's pipeline, register allocation (RA) might be
+ // split into multiple phases based on register class. So, this pass
+ // may be invoked multiple times requiring it to save these analyses to be
+ // used by RA later.
+ AU.addPreserved<LiveIntervals>();
+ AU.addPreserved<LiveDebugVariables>();
+
MachineFunctionPass::getAnalysisUsage(AU);
}
@@ -496,8 +506,10 @@ bool StackSlotColoring::RemoveDeadStores(MachineBasicBlock* MBB) {
++I;
}
- for (MachineInstr *MI : toErase)
+ for (MachineInstr *MI : toErase) {
MI->eraseFromParent();
+ Indexes->removeMachineInstrFromMaps(*MI);
+ }
return changed;
}
@@ -515,6 +527,7 @@ bool StackSlotColoring::runOnMachineFunction(MachineFunction &MF) {
TII = MF.getSubtarget().getInstrInfo();
LS = &getAnalysis<LiveStacks>();
MBFI = &getAnalysis<MachineBlockFrequencyInfo>();
+ Indexes = &getAnalysis<SlotIndexes>();
bool Changed = false;
|
@@ -496,8 +506,12 @@ bool StackSlotColoring::RemoveDeadStores(MachineBasicBlock* MBB) { | |||
++I; | |||
} | |||
|
|||
for (MachineInstr *MI : toErase) | |||
for (MachineInstr *MI : toErase) { | |||
if (Indexes) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't need braces
0c526ed
to
c56007d
Compare
@vg0204 Congratulations on having your first Pull Request (PR) merged into the LLVM Project! Your changes will be combined with recent changes from other authors, then tested Please check whether problems have been caused by your change specifically, as How to do this, and the rest of the post-merge process, is covered in detail here. If your change does cause a problem, it may be reverted, or you can revert it yourself. If you don't get any reports, no action is required from you. Your changes are working as expected, well done! |
…lvm#93779) The pass pipeline of some architecture splits register allocation phase based on different register classes. As some analyses need to be computed at the beginning of the register allocation and kept alive till all values are assigned to some physical registers. This poses challenge with objective of introducing StackSlotColoring after partial virtual registers are assigned to physical registers, in order to optimize stack slots usage.As this pass doesn't preserve few analysis yet to be needed by the register allocation of the remaining virtual registers, necessiating them to be kept preserved.
This PR is dependent on [#93779](#93779). As currently, each SGPR Spills are lowered to go into distinct stack slots in stack frame after SGPR allocation phase. Therefore, this patch utilizes the capability of StackSlotColoring to ensure the stack slot sharing if possible for stack frame index, where the SGPR spills are occuring in the non-interfering region. StackSlotColoring is introduced immediately after SGPR register allocation, just to ensure that any further lowering happens on the optimally allocated stack slots, with certain flags to indicate the preservation of certain analysis result later to be used by RA of other register classes.
This PR is dependent on [llvm#93779](llvm#93779). As currently, each SGPR Spills are lowered to go into distinct stack slots in stack frame after SGPR allocation phase. Therefore, this patch utilizes the capability of StackSlotColoring to ensure the stack slot sharing if possible for stack frame index, where the SGPR spills are occuring in the non-interfering region. StackSlotColoring is introduced immediately after SGPR register allocation, just to ensure that any further lowering happens on the optimally allocated stack slots, with certain flags to indicate the preservation of certain analysis result later to be used by RA of other register classes.
The pass pipeline of some architecture splits register allocation phase based on different register classes. As some analyses need to be computed at the beginning of the register allocation and kept alive till all values are assigned to some physical registers.
This poses challenge with objective of introducing StackSlotColoring after partial virtual registers are assigned to physical registers, in order to optimize stack slots usage.As this pass doesn't preserve few analysis yet to be needed by the register allocation of the remaining virtual registers, necessiating them to be kept preserved.