-
Notifications
You must be signed in to change notification settings - Fork 14.3k
AMDGPU: Don't avoid clamp of bit shift in BFE pattern #115372
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 |
---|---|---|
|
@@ -150,22 +150,14 @@ define i32 @bzhi32_c4_commutative(i32 %val, i32 %numlowbits) nounwind { | |
; ---------------------------------------------------------------------------- ; | ||
|
||
define i32 @bzhi32_d0(i32 %val, i32 %numlowbits) nounwind { | ||
; SI-LABEL: bzhi32_d0: | ||
; SI: ; %bb.0: | ||
; SI-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) | ||
; SI-NEXT: v_sub_i32_e32 v1, vcc, 32, v1 | ||
; SI-NEXT: v_lshlrev_b32_e32 v0, v1, v0 | ||
; SI-NEXT: v_lshrrev_b32_e32 v0, v1, v0 | ||
; SI-NEXT: s_setpc_b64 s[30:31] | ||
; | ||
; VI-LABEL: bzhi32_d0: | ||
; VI: ; %bb.0: | ||
; VI-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) | ||
; VI-NEXT: v_sub_u32_e32 v1, vcc, 32, v1 | ||
; VI-NEXT: v_lshlrev_b32_e32 v0, v1, v0 | ||
; VI-NEXT: v_lshrrev_b32_e32 v0, v1, v0 | ||
; VI-NEXT: s_setpc_b64 s[30:31] | ||
%numhighbits = sub i32 32, %numlowbits | ||
; GCN-LABEL: bzhi32_d0: | ||
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 isn't canonical IR. We shouldn't be burning compile time optimizing non-canonical IR. Can you add a copy of this test with the instcombine output, and revert this if you get the same output 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. Instcombine does not change the test source, and I think extracting the low bits are frequently used in the programs to restrict the range of a value. 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. Instcombine does change this:
Codegenning this does produce BFE already (except we fail to optimize out the clamp, which is a separate issue) |
||
; GCN: ; %bb.0: | ||
; GCN-NEXT: s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0) | ||
; GCN-NEXT: v_and_b32_e32 v1, 31, v1 | ||
; GCN-NEXT: v_bfe_u32 v0, v0, 0, v1 | ||
; GCN-NEXT: s_setpc_b64 s[30:31] | ||
%numlow5bits = and i32 %numlowbits, 31 | ||
%numhighbits = sub i32 32, %numlow5bits | ||
%highbitscleared = shl i32 %val, %numhighbits | ||
%masked = lshr i32 %highbitscleared, %numhighbits | ||
ret i32 %masked | ||
|
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.
No, this is completely wrong!!! E.g. if bit 0 is known to be 0 then
countMaxTrailingOnes
will return 0 and this test will pass.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.
Ugh, my bad, sorry.
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.
Thanks so much. Also countMaxActiveBits is more close to what we are going to define