-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[AMDGPU] Fix bad removal of s_delay_alu #145728
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 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 |
---|---|---|
|
@@ -3070,6 +3070,7 @@ define amdgpu_kernel void @flat_atomic_inc_ret_i32_offset_addr64(ptr %out, ptr % | |
; GFX12-NEXT: v_dual_mov_b32 v0, s0 :: v_dual_mov_b32 v1, s1 | ||
; GFX12-NEXT: v_add_co_u32 v0, vcc_lo, v0, v2 | ||
; GFX12-NEXT: s_wait_alu 0xfffd | ||
; GFX12-NEXT: s_delay_alu instid0(VALU_DEP_2) | ||
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. Not your fault, but I think this delay is unnecessary because of the fast-forward path from add-with-carry-out to add-with-carry-in. 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. should that be included as a separate change? 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. It should not be included in this PR. It would be a good thing to address in a separate PR, if you have some idea about how to implement it. |
||
; GFX12-NEXT: v_add_co_ci_u32_e64 v1, null, 0, v1, vcc_lo | ||
; GFX12-NEXT: flat_store_b32 v[0:1], v3 | ||
; GFX12-NEXT: s_endpgm | ||
|
@@ -4161,6 +4162,7 @@ define amdgpu_kernel void @flat_atomic_inc_ret_i64_offset_addr64(ptr %out, ptr % | |
; GFX12-NEXT: v_dual_mov_b32 v3, s1 :: v_dual_mov_b32 v2, s0 | ||
; GFX12-NEXT: v_add_co_u32 v2, vcc_lo, v2, v4 | ||
; GFX12-NEXT: s_wait_alu 0xfffd | ||
; GFX12-NEXT: s_delay_alu instid0(VALU_DEP_2) | ||
; GFX12-NEXT: v_add_co_ci_u32_e64 v3, null, 0, v3, vcc_lo | ||
; GFX12-NEXT: flat_store_b64 v[2:3], v[0:1] | ||
; GFX12-NEXT: s_endpgm | ||
|
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 function seems to be ignoring the handful of VALU instructions which do read SGPRs? Also inlineasm
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.
VALU->SGPR->VALU doesn't use VA_SDST counter, at least I haven't seen that
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.
Still needs to consider asm
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.
Right, this function is only supposed to be handle instruction types which are documented as waiting for all outstanding VALU-writing-SGPR instructions to complete. VALU themselves do not do that, they only wait if there is a dependency on a specific SGPR that they need to read.
Since there's no way to handle inlineasm correctly here without deep knowledge of the instructions it contains, I think ignoring inlineasm is the right thing to do. That's what the rest of this pass does. The whole pass is only an optimization anyway and can't affect correctness.