With the work to help consolidate GT_SIMD and GT_HWINTRINSIC so we largely have a single node type to maintain, optimize, etc, it would be good to determine where the boundary between FEATURE_SIMD and FEATURE_HW_INTRINSIC should be drawn.

The SIMDIntrinsicGetZero, SIMDIntrinsicInit, SIMDIntrinsicUpperSave, and SIMDIntrinsicUpperRestore intrinsics in particular are a bit special in that they are used more broadly than with just the System.Numerics code. They are currently used for things like block initialization and for properly handling any calling convention requirements around the upper bits of a vector register being saved/restored. So unlike many of the other intrinsics it isn't necessarily as simple as just porting the GT_SIMD nodes (which are FEATURE_SIMD) over to be GT_HWINTRINSIC nodes (which are FEATURE_HW_INTRINSICS or FEATURE_HW_INTRINSICS + FEATURE_SIMD).

That being said, the simplest solution would likely be to just fully consolidate FEATURE_SIMD and FEATURE_HW_INTRINSIC together such that you can't have one without the other. This would likely be the simplest to maintain given what we currently ship but would naturally restrict being able to just turn off certain functionality moving forward. This would not necessarily increase the bringup cost of new platforms as the Hardware Intrinsics are still table driven and so the ISAs can be brought on piece by piece. The NI_Vector64_*, NI_Vector128_*, and NI_Vector256_* represent what is essentially the "core functionality" and already include intrinsics equivalent to SIMDIntrinsicGetZero, SIMDIntrinsicInit, etc...

An alternative would be to keep both features and have FEATURE_SIMD represent the TYP_SIMD support and any "core" functionality such as the ABI handling and block initialization/copy. The difficulty then comes in maintaining that split and determining where things fall moving forward. Given the nature of the HWIntrinsics, most of the feature is just the codegen and emitter support for all the various SIMD instructions, the rest of it is largely just the name recognition and node creation support in the importer. While the actual name recognition that maps the framework methods to the corresponding intrinsic IDs is actually specific to the HWIntrinsic feature, the rest of it is largely just general compiler support that would also be used by FEATURE_SIMD and is ultimately dependent on what code we generate. For example, we would still need a node type to hold the equivalent of SIMDIntrinsicGetZero, we would likewise need the codegen and emitter support for the legacy and VEX encoding and would need this for all supported TYP_SIMD. SIMDIntrinsicInit is the same, but also has the support for creating method constants and for emitting generally "optimal" codegen based on the underlying hardware.

category:implementation
theme:vector-codegen
skill-level:intermediate
cost:medium
impact:small