-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[AMDGPU][True16][CodeGen] srl pattern for true16 mode #132987
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 |
---|---|---|
|
@@ -2425,6 +2425,13 @@ def : GCNPat <(i1 imm:$imm), | |
let WaveSizePredicate = isWave32; | ||
} | ||
|
||
let True16Predicate = UseRealTrue16Insts in | ||
foreach vt = [i32, v2i16] in | ||
def : GCNPat < | ||
(vt (DivergentBinFrag<srl> VGPR_32:$src, (i32 16))), | ||
(REG_SEQUENCE VGPR_32, (i16 (EXTRACT_SUBREG $src, hi16)), lo16, (V_MOV_B16_t16_e64 0, (i16 0x0000), 0), hi16) | ||
Comment on lines
+2431
to
+2432
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. Probably should teach performSRLCombine for the 16-bit case, it already handles 64-to-32 in the same way and could be generalized 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. Hi Matt. Thanks for the review. I checked the performSrlCombine function. I think it's currently checking for 64bit SRL with a dynamic right shift bits, which probably cannot be put in a isel pattern. I think for this case since the right shift bit is a constant 16, it's probably better to directly place it in the isel pattern. If we want to add another pattern for 32bit SRL with a dynamic right shift bit, the performSrlCombine function should be the right place 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 point is it doesn't need to be in an isel pattern. The shift combine subsumes the selection pattern 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 see. I will create another patch to address 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. Hi Matt. I tried put this lowering into SrlCombine, but seems not working. The sdagcombine happens before ISel selection, and thus we don't have info about register at that time. Putting it in SrlCombine might get it lowered to sgpr_hi/lo16 which does not work. I think we might be able to do this after we have spgr 16bit in place 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. But the registers shouldn't matter? The problem isn't any different than the current 16-bit vs. 32-bit uniform problem. As a proxy you can just check if the value is uniform? 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. Hi Matt. I think we are talking about two issues here. The first thing is the 16-bit vs. 32-bit uniform problem, that we can teach the SrlCombine and the promoteUniformOp to use 16bit. Eventually they get lower to smaller size SRL, and finally get lowered to LSHRREV. Another thing is the what this patch is trying to do. For VGPR 16bit right shift, we do not lower to LSHRREV, but use REG_SEQUENCE with .l/.h access as it generates better code. This depends on register type since we don't have sgpr 16 support yet |
||
>; | ||
|
||
/********** ================== **********/ | ||
/********** Intrinsic Patterns **********/ | ||
/********** ================== **********/ | ||
|
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.
I don't see how this pattern makes sense for the v2i16 case
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.
Hi Matt. I thought this works for any 16bit right shift on a VGPR_32. Why do you think this will not work for v2i16?
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.
A shift of 16 on an i32 takes the top half of the integer. A splat shift of 16 on a v2i16 is an out of bounds shift
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.
I might misunderstood srl on vector type. Let me try something and I will address this in the follow up patch
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.
Create a patch here #133458