Eliminate the need to preserve struct handles for `SIMD` types

[SingleAccretion]

Currently, we require most TYP_SIMD nodes in IR to "have" a struct handle (i. e. return something concrete from gtGetStructHandleIfPresent).

This:

1. Results in confusing invariants because "most" is not "all". E. g. it is legal to have a local variable of TYP_SIMD without a handle.
2. Makes introducing new nodes that have TYP_SIMD harder (e. g.: Adding support for vector constants via GenTreeVecCon #68874 (comment)).
3. Makes using TYP_SIMD nodes in IR internally risky, as we must either be able to find some usable handle the user code contained (what the current caching scheme attempts to do) or be very careful not to use the "handle-less" nodes in contexts where a handle might be required of them later on.
4. Is a canonicalization problem: is the "canonical" indirection for TYP_SIMD an OBJ or an IND? Currently, it's both, with somewhat fragile code in morph that tries to turn one into another, and for copies only.

This requirement is mostly historical, and in my opinion, the best solution to the above problems is to simply eliminate it. Things that need the precise handle (CALLs) should acquire them in other ways.

category:design
theme:structs
skill-level:expert
cost:medium
impact:small

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

Issue Details

---

Currently, we require most TYP_SIMD nodes in IR to "have" a struct handle (i. e. return something concrete from gtGetStructHandleIfPresent).

This:

1. Results in confusing invariants because "most" is not "all". E. g. it is legal to have a local variable of TYP_SIMD without a handle.
2. Makes introducing new nodes that have TYP_SIMD harder (e. g.: Adding support for vector constants via GenTreeVecCon #68874 (comment)).
3. Makes using TYP_SIMD nodes in IR internally risky, as we must either be able to find some usable handle the user code contained (what the current caching scheme attempts to do) or be very careful not to use the "handle-less" nodes in contexts where a handle might be required of them later on.
4. Is a canonicalization problem: is the "canonical" indirection for TYP_SIMD an OBJ or an IND? Currently, it's both, with somewhat fragile code in morph that tries to turn one into another, and for copies only.

This requirement is mostly historical, and in my opinion, the best solution to the above problems is to simply eliminate it. Things that need the precise handle (CALLs) should acquire them in other ways.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[SingleAccretion]

cc @dotnet/jit-contrib, @tannergooding for opinions. This is not something I am planning to work on in the near future, but something I think would be a good long-term direction for our varTypeIsStruct(...) code.

[tannergooding]

I'd definitely like for this to be fixed and agree that the underlying type is largely irrelevant.

It shouldn't matter if you have a Vector128<float> or Vector128<byte> or a Vector4. All three of these are enregistered the same and exist on the stack in the same way. Likewise they have nop casts available between them and which are used in the JIT.

The places that they do differ are things like as struct fields (Vector128<T> has 16-byte packing, Vector4 has 4-byte packing) or when passed as a method parameter (Vector128<T> is the __m128 ABI type, Vector4 is an HFA). In these other cases you almost always have another handle available (such as the struct handle or method handle) that describes the actual type that's necessary.

In the case of a call, even if you have something that says "I'm a Vector4", if the method expects a Vector128<float> arg then the method expects it be passed as the __m128 ABI type. Likewise for something like a GenTreeHWIntrinsic Add CORINFO_TYPE_FLOAT, regardless of what the underlying operand says its type is it will get interpreted as a Vector128<float>.

[jakobbotsch]

Is this still relevant?

[SingleAccretion]

Yes. E. g. we still use OBJs for SIMD in importer.

[SingleAccretion]

E. g. we still use OBJs for SIMD in importer.

Fixed in #84868.