-
Notifications
You must be signed in to change notification settings - Fork 14.6k
[X86][BreakFalseDeps] Using reverse order for undef register selection #137569
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
Changes from 3 commits
cacb6c5
4ecabc7
6d6f655
5c58952
ddbed2a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -39,14 +39,16 @@ StressRA("stress-regalloc", cl::Hidden, cl::init(0), cl::value_desc("N"), | |
|
||
RegisterClassInfo::RegisterClassInfo() = default; | ||
|
||
void RegisterClassInfo::runOnMachineFunction(const MachineFunction &mf) { | ||
void RegisterClassInfo::runOnMachineFunction(const MachineFunction &mf, | ||
bool Rev) { | ||
bool Update = false; | ||
MF = &mf; | ||
|
||
auto &STI = MF->getSubtarget(); | ||
|
||
// Allocate new array the first time we see a new target. | ||
if (STI.getRegisterInfo() != TRI) { | ||
if (STI.getRegisterInfo() != TRI || Reverse != Rev) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This TRI check looks broken, shouldn't be necessary There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TRI is a constant value within the same Subtarget, but can be changed when we compile functions with different target feature. So we need to reset RegClass in these cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The analysis shouldn't survive in those cases? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My understanding is RegClass survives longer than analysis. We have other passes like MachineSink, RegAllocBase, MachineCombiner etc. all use it. The cached RegClass can be used among them within the same Subtarget? |
||
Reverse = Rev; | ||
TRI = STI.getRegisterInfo(); | ||
RegClass.reset(new RCInfo[TRI->getNumRegClasses()]); | ||
Update = true; | ||
|
@@ -142,7 +144,12 @@ void RegisterClassInfo::compute(const TargetRegisterClass *RC) const { | |
|
||
// FIXME: Once targets reserve registers instead of removing them from the | ||
// allocation order, we can simply use begin/end here. | ||
ArrayRef<MCPhysReg> RawOrder = RC->getRawAllocationOrder(*MF); | ||
ArrayRef<MCPhysReg> RawOrder = RC->getRawAllocationOrder(*MF, Reverse); | ||
std::vector<MCPhysReg> ReverseOrder; | ||
if (Reverse) { | ||
llvm::append_range(ReverseOrder, reverse(RawOrder)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I probably miss something but why can't we define the correct reverse order in Something like
I think There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The reason to customize |
||
RawOrder = ArrayRef<MCPhysReg>(ReverseOrder); | ||
} | ||
Comment on lines
+147
to
+152
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is already a mechanism for providing alternative allocation orders defined in tablegen, you shouldn't need to do this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, this is to imitate the alternative allocation order way. Currently it's only controlled by target features. We want to control it through pass agrument too. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's wrong with it being a target faster? Could also expand the alternative allocation order controls. This is hardcoding a single alternative choice and requires a runtime sort There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The problem is not some registers are fast. They are all the same. The intention here is to alter the order for the a specific pass. It doesn't solve the problem here if we just reverse register oder for all passes. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. s/faster/feature/ Then change the selection mechanism for the table generated order There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see how feature help here. This is not some feature works for all passes. We just want BreakFalseDeps uses reverse order. |
||
for (unsigned PhysReg : RawOrder) { | ||
// Remove reserved registers from the allocation order. | ||
if (Reserved.test(PhysReg)) | ||
|
Uh oh!
There was an error while loading. Please reload this page.