JIT: Illegal instruction at JitTest_chain_boxunbox_il.Test.Main() under DOTNET_JitStressRegs=0x2000

[saucecontrol]

Description

Seen in two separate PRs on the runtime-coreclr jitstress-isas-avx512 pipeline.

https://dev.azure.com/dnceng-public/public/_build/results?buildId=939955 for #111778

and

https://dev.azure.com/dnceng-public/public/_build/results?buildId=939970 for #111853

Reproduction Steps

View logs for the above CI runs

22:36:26.039 Running test: JIT/Methodical/Boxing/boxunbox/chain_d/chain_d.dll
Fatal error. System.ExecutionEngineException: Illegal instruction: Attempted to execute an instruction code not defined by the processor.
   at JitTest_chain_boxunbox_il.Test.Main()
   at Program.<<Main>$>g__TestExecutor80|0_81(System.IO.StreamWriter, System.IO.StreamWriter, <>c__DisplayClass0_0 ByRef)
   at Program.<Main>$(System.String[])

22:45:42.226 Running test: JIT/Methodical/Boxing/boxunbox/chain_r/chain_r.dll
Fatal error. System.ExecutionEngineException: Illegal instruction: Attempted to execute an instruction code not defined by the processor.
   at JitTest_chain_boxunbox_il.Test.Main()
   at Program.<<Main>$>g__TestExecutor80|0_81(System.IO.StreamWriter, System.IO.StreamWriter, <>c__DisplayClass0_0 ByRef)
   at Program.<Main>$(System.String[])

Expected behavior

No failures

Actual behavior

Illegal Instruction crash

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[saucecontrol]

Same instruction in both cases

00007ffc`9fb216b4 62c17e00104702  vmovss  xmm16,dword ptr [r15+8] ds:0000000a`be37d6d2=7ffc9e8f

00007ff8`7bef16b4 62c17e00104702  vmovss  xmm16,dword ptr [r15+8] ds:0000001c`6ed7d782=7ff87acc

Looks like the 00 4th byte is wrong.

[AndyAyersMS]

cc @dotnet/jit-contrib

Likely from some of the recent xarch emitter changes?

[BruceForstall]

Maybe #108796? @Ruihan-Yin

[Ruihan-Yin]

I can reproduce the bug locally, looking into it.

[Ruihan-Yin]

The wrong encoding comes from code pieces like this:

JIT did the codegen in the form of vmovss xmm, xmm, m32, but this instructions does not actually have this form.

It looks more like a code gen problem, instead of encoding bug, where INS_movss should not hit emitIns_R_R_A path.

From the stack, I believe the bug is from genCodeForCast, that when ins is vmovss, the code gen function should be sth other than emitIns_R_R_A.

[saucecontrol]

Ah, this may have been exposed by #111595 then.

That one showed some removed float->double->float casts in the diffs, but those may have actually ended up as float->float in some cases, and this looks suspect:

runtime/src/coreclr/jit/instr.cpp

Line 2481 in 2faef6d

return ins_Move_Extend(TYP_FLOAT, false);

[Ruihan-Yin]

I can try to fix and file a PR for it if there is no ongoing work for this bug. It will be nice to have it fixed since some of our PRs are also hitting this problem.