-
Notifications
You must be signed in to change notification settings - Fork 15.3k
[AMDGPU] Reflect amdgpu-waves-per-eu attribute minimum occupancy to RegPressure analysis (used in machine licm, machine scheduler, and register allocation) #167390
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
base: main
Are you sure you want to change the base?
Changes from all commits
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 |
|---|---|---|
|
|
@@ -3758,6 +3758,11 @@ bool SIRegisterInfo::shouldCoalesce(MachineInstr *MI, | |
| unsigned SIRegisterInfo::getRegPressureLimit(const TargetRegisterClass *RC, | ||
| MachineFunction &MF) const { | ||
| unsigned MinOcc = ST.getOccupancyWithWorkGroupSizes(MF).first; | ||
| Function &F = MF.getFunction(); | ||
| if (AMDGPU::getIntegerPairAttribute(F, "amdgpu-waves-per-eu", true) != | ||
| std::nullopt) { | ||
| MinOcc = ST.getWavesPerEU(F).first; | ||
| } | ||
|
Contributor
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. Why isn't this pressure limit computed with RegisterClassInfo? I would assume all of the pressure information is implied by the register counts, which are already set by the occupancy, and wouldn't require manual intervention in terms of the occupancy
Contributor
Author
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. All I can say is that this is the value used by machine licm, pre-RA machine scheduler, and RA ---- and the minimum occupancy computed here, without this patch, is different from what you can get from MachineFunctionInfo's WavesPerEU (that comes from getWavesPerEU). Such inconsistency is certainly not desirable ---- but I need those who are in the experts in the area address that bigger problem. Trying to be consistent one way or the other way (probably one becoming default and choosing the other under an option), I expect a lot of GPU ASM churn to happen. This patch is just addressing a small but obvious problem while waiting for the bigger problem to be discussed/resolved. I'm fine if others don't like this patch going in ---- we can keep discussing how to resolve the inconsistency issue.
Contributor
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'm confused by the state of the MachineFunctionInfo field. It's a scalar, but it really should be a range. It changes mid-scheduling, so I'm not sure how to reconcile it. I'd hope it stays within the bounds of getWavesPerEU |
||
| switch (RC->getID()) { | ||
| default: | ||
| return AMDGPUGenRegisterInfo::getRegPressureLimit(RC, MF); | ||
|
|
||
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.
This should not be using the low level parsing utility and directly use getWavesPerEU
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.
That's exactly the point of
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.
Not sure I follow, but you shouldn't be trying to glean meaning from there being an explicit attribute or not. getWavesPerEU should be the authoritative range to use
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.
yeah, IIUC the attribute is guaranteed ABI.
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.
It's not quite ABI but essentially
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 it's important there is no distinction between default value and attribute set to default