Remove 128-bit limit on Vector<T> size for ARM64#129852
Conversation
If InstructionSet_VectorT is available, set the class instance size to the process SVE vector length. Increase the maximum bound in structMightRepresentSIMDType to allow the JIT to detect this when the ISA is present.
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
…Type Refactor the function to take in the class handle and query flag and size properties from the handle. Use the flag properties to optimize the function.
| #ifdef FEATURE_SIMD | ||
| return (structSize >= getMinVectorByteLength()) && (structSize <= getMaxVectorByteLength()); | ||
| #ifdef TARGET_ARM64 | ||
| const uint32_t max = compExactlyDependsOn(InstructionSet_VectorT) ? MAX_SVE_REGSIZE_BYTES : FP_REGSIZE_BYTES; |
There was a problem hiding this comment.
nit: Might be good to have a comment explaining why we check MAX_SVE_REGSIZE_BYTES (256) instead of getMaxVectorByteLength and the size that Vector<T> will be here....
In particular, I'd expect that Vector<T> be either 0 or SIZE_UNKNOWN here, and so it isn't clear why the check will "pass" for it.
There was a problem hiding this comment.
Ah, I guess SIZE_UNKNOWN is 255, so it'd qualify as under 256.
There was a problem hiding this comment.
We shouldn't see the VM report SIZE_UNKNOWN anyway at the moment. There was greater risk of that happening while the function was taking in a size integer, passing the class handle mitigates that use as well.
There was a problem hiding this comment.
I do agree a comment is needed here though. IIUC, AVX will support compilation for a number of VLs up to the maximum value available (is it ever possible to see AVX-512 on it's own?).
For SVE it's just going to be one VL somewhere in the range 128-2048 bit, so getMaxVectorByteLength doesn't quite have the same use case here.
There was a problem hiding this comment.
(is it ever possible to see AVX-512 on it's own?).
It is not, xarch currently requires that it be incremental and so V512 support implies V256 support, which itself implies V128 support (which technically implies V64 support, but MMX is legacy/slow and we don't support or expose it)
For SVE it's just going to be one VL somewhere in the range 128-2048 bit, so getMaxVectorByteLength doesn't quite have the same use case here.
Right. I wonder even if that means it should be "special" and effectively a check for "is within this range or exactly this well known type", so in the case of Arm64 being (size is >= 8 and <= 16) || (size == SIZE_UNKNOWN).
Probably not impactful now that we're filtering to only intrinsic types, but it is a bit unique in the overall setup.
|
CC. @dotnet/jit-contrib, @EgorBo, @dhartglassMSFT for secondary review on this Arm contribution. |
| @@ -10596,10 +10596,27 @@ class Compiler | |||
|
|
|||
| // Use to determine if a struct *might* be a SIMD type. As this function only takes a size, many | |||
There was a problem hiding this comment.
"As this function only takes a size..." is out of date now :)
There was a problem hiding this comment.
I've updated the comment on this function.
If
InstructionSet_VectorTis available, set the class instance size to the process SVE vector length.Increase the maximum bound in
structMightRepresentSIMDTypeto allow the JIT to detect this when the ISA is present.