AVX2_ro fails with jitstress=2

[AndyAyersMS]

Forked from #9964 / dotnet/coreclr#17330.

x64 checked build. AVX2_ro fails to validate with jitstress=2. The BlendVariable<Byte> are the ones failing.

Avx2.BlendVariable<Byte>(Vector256<Byte>, Vector256<Byte>, Vector256<Byte>): RunBasicScenario_Load failed:
   firstOp: (63, 251, 58, 216, 203, 64, 178, 128, 158, 102, 241, 93, 117, 12, 119, 40, 204, 56, 100, 37, 64, 108, 251, 16, 7, 29, 119, 127, 144, 21, 114, 30)
  secondOp: (151, 55, 219, 192, 119, 228, 54, 168, 120, 32, 66, 32, 41, 148, 50, 0, 40, 175, 220, 151, 239, 227, 58, 209, 0, 41, 208, 173, 200, 50, 238, 136)
   thirdOp: (128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1, 128, 1)
    result: (151, 251, 219, 216, 119, 64, 54, 128, 120, 102, 66, 93, 41, 12, 50, 40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0)
... etc ... 

cc @dotnet/jit-contrib @RussKeldorph @fiigii

[fiigii]

I will look into it tonight, I guess it is also a test template issue.

[AndyAyersMS]

I kind of doubt that -- it doesn't fail w/o jit stress.

Jit stress can do all sorts of interesting things to the IR.

[fiigii]

@AndyAyersMS I cannot reproduce this failure on my local machine...

[AndyAyersMS]

It is failing for me and also pretty readily in CI, eg here.

If you can't repro then I'll do some debugging tomorrow.

[fiigii]

If you can't repro then I'll do some debugging tomorrow.

Thank you so much for the help. I am in a business traveling these two days, so I may not be able to do debugging. But if you have any problem or progress, please let me now.

[CarolEidt]

This fails on my AVX2 system, but not the one with just AVX.

@AndyAyersMS if you have not already started working on this, let me know and I can take a look at it.

[AndyAyersMS]

@CarolEidt it's all yours.

[CarolEidt]

This is an issue with saving & restoring the upper halves of the ymm registers. In this case, two TYP_SIMD32 operands of a SIMD intrinsics appear in the execution order before a call, even though they aren't used until after the call. They are both last uses.
The last use bits are used when building the RefPositions to check whether a variable is live across a call. However, they should be checked at the point of use rather than at the point where the lclVar is encountered in the execution stream.
In this case, they are removed from the live set before the call is encountered, so they aren't saved & restored. The same bug exists in the non-stress version of the code, but inlining stress has caused the called method to use (and trash) more registers.
I'm working on a fix.