Introduce TYP_SIMD to the JIT for Vector<T> #121548
Conversation
The type is experimental and will only be materialized on ARM64, when DOTNET_JitUseScalableVectorT=1. This change covers initial properties of the type and pattern matching the type during import.
github-actions
bot
added
the
area-CodeGen-coreclr
dotnet-policy-service
bot
added
the
community-contribution
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
@dotnet/arm64-contrib |
src/coreclr/jit/simd.cpp
Outdated
| JITDUMP(" Found Vector<%s>\n", varTypeName(JitType2PreciseVarType(simdBaseJitType))); | ||
|
|
||
| #ifdef TARGET_ARM64 | ||
| if (compExactlyDependsOn(InstructionSet_Sve_Arm64) && JitConfig.JitUseScalableVectorT()) |
There was a problem hiding this comment.
nit: We want these swapped so that we aren't tagging a R2R or other images as requiring SVE unnecessarily.
It may even be desired for this to be an opportunistic check since the behavior in safe code is behaviorally the same. Its largely an optimization to use larger vectors.
There was a problem hiding this comment.
I forgot this has a side effect. Will swap it around.
Agreed this should be opportunistic. We'll want to respect the user choices of features.
src/coreclr/jit/typelist.h
Outdated
| DEF_TP(SIMD32 ,"simd32" , TYP_SIMD32, 32,32, 32, 8,16, VTR_FLOAT, availableDoubleRegs, RBM_FLT_CALLEE_SAVED, RBM_FLT_CALLEE_TRASH, VTF_S|VTF_VEC) | ||
| DEF_TP(SIMD64 ,"simd64" , TYP_SIMD64, 64,64, 64, 16,16, VTR_FLOAT, availableDoubleRegs, RBM_FLT_CALLEE_SAVED, RBM_FLT_CALLEE_TRASH, VTF_S|VTF_VEC) | ||
| #elif defined(TARGET_ARM64) | ||
| DEF_TP(SIMD ,"simd" , TYP_SIMD, SZU,EAU,EAU, 0,16, VTR_FLOAT, availableDoubleRegs, RBM_FLT_CALLEE_SAVED, RBM_FLT_CALLEE_TRASH, VTF_VEC) |
There was a problem hiding this comment.
Do we want to classify this as a structure with VTF_S? Not doing so seems to be turning off quite a few code paths that would be problematic for something without a size, which is good. Can you have a structure that doesn't have a size, in principal?
There was a problem hiding this comment.
I expect we'll have a number of places to fixup in either case.
If we don't mark it as a struct, we'll have a lot of places to update to ensure it gets the same optimizations, lightup, and general handling.
If we do mark it as a struct, there will be a number of places that need to be updated to handle "unknown size".
I expect marking it as a struct to be inline with the other SIMD types is the better approach.
Can you have a structure that doesn't have a size, in principal?
It's not that it doesn't have a size (i.e. 0), it's that the size is unknown (at least 16 and up to 256 bytes).
2 participants
The type is experimental and will only be materialized on ARM64, when
DOTNET_JitUseScalableVectorT=1. This change covers initial properties of the type and pattern matching the type during import.