Ensure vextractf64x4 and vextracti64x4 aren't marked DstDstSrc #85030
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsThis resolves #84967
|
| @@ -611,8 +611,8 @@ INST3(FIRST_AVX512_INSTRUCTION, "FIRST_AVX512_INSTRUCTION", IUM_WR, BAD_CODE, BA | |||
| INST3(kmovw_gpr, "kmovw", IUM_WR, BAD_CODE, BAD_CODE, PCKFLT(0x92), INS_TT_NONE, REX_W0 | Encoding_VEX | KInstruction) | |||
| INST3(kmovw_msk, "kmovw", IUM_WR, PCKFLT(0x91), BAD_CODE, PCKFLT(0x90), INS_TT_NONE, REX_W0 | Encoding_VEX | KInstruction) | |||
| INST3(kortestw, "kortestw", IUM_WR, BAD_CODE, BAD_CODE, PCKFLT(0x98), INS_TT_NONE, REX_W0 | Encoding_VEX | Resets_OF | Resets_SF | Writes_ZF | Resets_AF | Resets_PF | Writes_CF | KInstruction) | |||
| INST3(vextractf64x4, "extractf64x4", IUM_WR, SSE3A(0x1B), BAD_CODE, BAD_CODE, INS_TT_TUPLE4, Input_64Bit | REX_W1_EVEX | Encoding_EVEX | INS_Flags_IsDstDstSrcAVXInstruction) // Extract 256-bit packed double-precision floating point values | |||
There was a problem hiding this comment.
DstDstSrc, DstSrcSrc, and others are somewhat "poor" names.
They originally existed because we didn't have proper VEX support and everything was considered RMW. So, when we went from encoding things in ModRM:reg and ModRM:r/m into also having a new VEX.vvvv "field", we needed a way to track how that field should be encoded without also doing the more significant work around "properly" supporting VEX and treating things as non-RMW
Since the vast majority of instructions were of the form ins reg, r/m these flags were basically used to indicate whether we duplicated the Dst (ModRM:reg) or Src (ModRM:r/m) register into the VEX.vvvv field. -- This "worked" because we also didn't really support containment for stores of hwintrinsics at all, so we never really had to care about ModRM:r/m being the Dst.
Today, we do support VEX properly, don't require everything to be viewed as RMW, and do also support generating stores for HWIntrinsics. So, it might be good to rethink the flag names a bit in the near future. Namely, we really just care about which operands go into which of the three ModRM:reg, VEX.vvvv, and ModRM:r/m (with that particular order for Dst, Op1, Op2 being the most common) and so there's probably something there in how we track things that will end up working and being clearer as to what it means
|
CC. @BruceForstall, @dotnet/avx512-contrib, @dotnet/jit-contrib |
|
Failure is a timeout caused by a missing line in the crossgen VM code. I have that fixed as part of #85026 |
This resolves #84967