JIT: mark vpshufbitqmb as a three-operand AVX instruction - #134287
Open
jamesburton wants to merge 2 commits into
Open
jamesburton wants to merge 2 commits into
jamesburton wants to merge 2 commits into
Conversation
VPSHUFBITQMB has the form 'k1 {k2}, xmm2, xmm3/m128' -- a kmask
destination plus two source operands. Every other three-operand
mask-producing EVEX instruction in instrsxarch.h carries
INS_FLAGS_IsDstDstSrcAVXInstruction (vpcmpb, vpcmpub, vpcmpw, vpcmpuw,
vptestmb/d/q/w, vptestnmb/d/q/w, vpblendmb); vpshufbitqmb does not.
Without the flag IsThreeOperandAVXInstruction returns false, so any
attempt to emit the instruction asserts in emitIns_R_R_S
(emitxarch.cpp:8572) on a Checked JIT, and would emit a malformed
encoding on Release.
The row is currently unreachable -- no HARDWARE_INTRINSIC entry maps to
INS_vpshufbitqmb -- so no shipping code is affected today. It was found
while implementing the BITALG intrinsics for dotnet#96162, whose
Avx512BitAlg.ShuffleBits would be the first consumer. Fixing it
separately so the table is correct independently of that work.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
github-actions
Bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
Bot
added
the
community-contribution
|
Azure Pipelines: Successfully started running 5 pipeline(s). 11 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
Contributor
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The change is a low-risk metadata fix confined to the instruction table, with only a minor formatting nit noted in review comments.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Updates the x86 instruction metadata table so vpshufbitqmb is classified as a three-operand AVX instruction (dst + two sources), aligning it with other EVEX mask-producing instructions and preventing emitter assertions when/if a future consumer starts using this instruction.
Changes:
- Add
INS_FLAGS_IsDstDstSrcAVXInstructionto thevpshufbitqmbrow ininstrsxarch.h.
| File | Description |
|---|---|
| src/coreclr/jit/instrsxarch.h | Marks vpshufbitqmb as a 3-operand AVX instruction in the instruction table metadata. |
| INST3(vpshrdvw, "vpshrdvw", IUM_WR, BAD_CODE, BAD_CODE, SSE38(0x72), ILLEGAL, ILLEGAL, INS_TT_FULL_MEM, Input_16Bit | KMask_Base8 | REX_W1 | Encoding_EVEX) // Concatenate and Variable Shift Packed Data Right Logical | ||
| INST3(vpshrdw, "vpshrdw", IUM_WR, BAD_CODE, BAD_CODE, SSE3A(0x72), ILLEGAL, ILLEGAL, INS_TT_FULL_MEM, Input_16Bit | KMask_Base8 | REX_W1 | Encoding_EVEX) // Concatenate and Shift Packed Data Right Logical | ||
| INST3(vpshufbitqmb, "vpshufbitqmb", IUM_WR, BAD_CODE, BAD_CODE, SSE38(0x8F), 6C, 1C, INS_TT_FULL_MEM, Input_8Bit | KMask_Base16 | REX_W0 | Encoding_EVEX) // Shuffle Bits From Quadword Elements Using Byte Indexes Into Mask | ||
| INST3(vpshufbitqmb, "vpshufbitqmb", IUM_WR, BAD_CODE, BAD_CODE, SSE38(0x8F), 6C, 1C, INS_TT_FULL_MEM, Input_8Bit | KMask_Base16 | REX_W0 | Encoding_EVEX | INS_FLAGS_IsDstDstSrcAVXInstruction) // Shuffle Bits From Quadword Elements Using Byte Indexes Into Mask |
Member
There was a problem hiding this comment.
This feedback is correct and should be accounted for
Addresses the Copilot review nit: the added flag had compressed the REX_W0 / Encoding_EVEX columns. Now matches the surrounding rows and vptestmb's formatting exactly (Encoding_EVEX at column 255). Whitespace only; no functional change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #134286.
VPSHUFBITQMBhas the formk1 {k2}, xmm2, xmm3/m128— a kmask destination plus two source operands — but its row ininstrsxarch.hwas missingINS_FLAGS_IsDstDstSrcAVXInstruction. Every other three-operand mask-producing EVEX instruction in the table has it:vptestmb/d/q/w,vptestnmb/d/q/w,vpcmpb,vpcmpub,vpcmpw,vpcmpuw,vpblendmb.IsThreeOperandAVXInstructionis a straight lookup ofINS_FLAGS_Is3OperandInstructionMask, so without the flag it returnsfalseandemitIns_R_R_S/emitIns_R_R_R_I/emitIns_R_R_S_Iassert:No shipping code is affected. Nothing maps to
INS_vpshufbitqmbtoday — the row has been dormant since it was added, which is why this went unnoticed. This is a latent table defect, so there is no regression test to add here; the instruction has no reachable code path to test until a consumer exists.Found while implementing the
BITALGintrinsics for #96162, whereAvx512BitAlg.ShuffleBitsbecomes the first consumer and trips the assert immediately. Sending it separately so the table is correct regardless of what happens to that work.Validation
Verified locally on Zen 5 (AMD Strix Halo, which supports BITALG), Checked JIT:
VPOPCNTDQandBITALGIntrinsics #96162 intrinsics wired up,ShuffleBitsemits and executes correctly acrossVector128/256/512for bothbyteandsbyte, at Tier0 and withDOTNET_TieredCompilation=0;JIT/HardwareIntrinsics/X86_Avx512suite passes 1775/1775;I also checked
vpcmpd/vpcmpq/vpcmpud/vpcmpuq, which lack the flag while theirb/wsiblings have it and are reachable. Empirically they do not reach any asserting emit path (Vector512.LessThanOrEqual<int>,GreaterThan<uint>,LessThan<ulong>, register and memory operands, Checked JIT), so I have left them alone — noted in the issue in case they should be made consistent.🤖 Generated with Claude Code