Test failure: Assertion failed '!"SIMD intrinsic with unsupported base type."'

[BruceForstall]

Windows x64 JitStress=1 or 2

Test:

JIT\SIMD\VectorRelOp_ro\VectorRelOp_ro.cmd

https://dev.azure.com/dnceng/public/_build/results?buildId=631203&view=ms.vss-test-web.build-test-results-tab&runId=19687756&resultId=105979&paneView=debug

\r\nAssert failure(PID 6688 [0x00001a20], Thread: 7948 [0x1f0c]): Assertion failed '!"SIMD intrinsic with unsupported base type."' in 'VectorRelopTest1[UInt64][System.UInt64]:VectorRelOp(long,long):int' during 'Generate code' (IL size 1179)\r\n\r\n File: F:\workspace_work\1\s\src\coreclr\src\jit\simdcodegenxarch.cpp Line: 3201\r\n Image: C:\h\w\AB7209D8\p\CoreRun.exe\r\n\r\n\r\nReturn code: 1\r\nRaw output file: C:\h\w\AB7209D8\w\C2150A43\e\JIT\SIMD\Reports\JIT.SIMD\VectorRelOp_ro\VectorRelOp_ro.output.txt\r\nRaw output:\r\nBEGIN EXECUTION\r\n "C:\h\w\AB7209D8\p\corerun.exe" VectorRelOp_ro.dll \r\nExpected: 100\r\nActual: -1073740286\r\nEND EXECUTION - FAILED\r\nFAILED\r\nTest Harness Exitcode is : 1\r\nTo run the test:\r\n> set CORE_ROOT=C:\h\w\AB7209D8\p\r\n> C:\h\w\AB7209D8\w\C2150A43\e\JIT\SIMD\VectorRelOp_ro\VectorRelOp_ro.cmd\r\nExpected: True\r\nActual: False`

[BruceForstall]

@dotnet/jit-contrib

[tannergooding]

This may be related to #35877, both seem related to an unsupported Vector type.

[tannergooding]

This is a manifestation of #35620.

The simplest "solution" is probably to have insertUpperVectorSave and impUpperVectorRestore lie about the base type if varDsc->lvBaseType is TYP_UNDEF. The codegen always uses INS_vextractf128 and INS_insertps today anyways and doesn't actually care if a baseType is even set.

A more involved change might be to actually utilize GenTreeJitIntrinsic.m_layout (which looks to be unused today) to actually track the correct underlying handle even if we are lying about the base type. Although, I think if we want to support #11062, then we might want this to be a CORINFO_METHOD_HANDLE like we have on GenTreeIntrinsic, so we can later rewrite the intrinsic to be a user call. Having CORINFO_METHOD_HANDLE would also allow us to always get the correct underlying handle as we can get the handle of the return type (and you could of course still get the layout from that handle as well).

[tannergooding]

I put up a fix that sets the baseType to TYP_FLOAT so that the outer loop can be unblocked: #35899

[CarolEidt]

A more involved change might be to actually utilize GenTreeJitIntrinsic.m_layout (which looks to be unused today) to actually track the correct underlying handle even if we are lying about the base type.

Yes that was introduced in anticipation of handling intrinsics that return a ValueTuple at the time I restructured the IR to handle multi-reg locals. (The HW intrinsics will also require support for multiple registers when we support intrinsics returning a ValueTuple). The idea was that we would add the correct layout for all HW intrinsics, to eliminate some of the hacky handling of struct handles for SIMD types.

I think it's reasonable for now to set the base type to TYP_FLOAT.