API Proposal : Arm64 Load & Store

[sdmaclea]

Edit: Removed StaticCast as that is handled by Vector128.As*. Kept the Load/Store APIs as generic with note that the actual implementation is exploded and supports all 10 primitive types

namespace System.Runtime.Intrinsics.Arm
{
    public abstract class AdvSimd 
    {
        public abstract class Arm64
        {
            /// <summary>
            /// Vector load
            ///
            /// Corresponds to vector form of ARM64 LDR
            /// </summary>
            public static unsafe Vector64<T>  LoadVector64<T>(void* address) where T : struct { throw null; }
            public static unsafe Vector128<T> LoadVector128<T>(void* address) where T : struct { throw null; }
    
            /// <summary>
            /// Vector store
            ///
            /// Corresponds to vector form of ARM64 STR
            /// </summary>
            public static unsafe void Store<T>(void* address, Vector64<T>  source) where T : struct { throw null; }
            public static unsafe void Store<T>(void* address, Vector128<T> source) where T : struct { throw null; }
        }
    }
}

[sdmaclea]

These are similar to similarly named methods in X86.

The unsafe Load* and Store are basically identical to X86.

X86 has StaticCast which I suspect is what I have called ReinterpretCast. Static cast seems to imply conversion. Since I intend no conversion, this seemed to be the correct name.

@eerhardt @CarolEidt @RussKeldorph PTAL
@tannergooding @4creators @dotnet/arm64-contrib @dotnet/jit-contrib @fiigii FYI

[fiigii]

public static unsafe Vector64 LoadVector64(T* address) where T : struct { throw null; }

As I know, C# does not have pointers to generic types.

[sdmaclea]

C# does not have pointers to generic types.

Interesting... I think it is reasonable to review as is with the understanding that these may need to expand.

[fiigii]

X86 has StaticCast which I suspect is what I have called ReinterpretCast. Static cast seems to imply conversion. Since I intend no conversion, this seemed to be the correct name.

I am not sure if we should match the C++ name (actually, I do not think static_cast is a good name in C++ when it is used on value-types).

When I designed the API, I thought StaticCast<T, U> means that cast the type to make the static type system happy and no any dynamic conversion.

I am happy to hear more comments from C# experts. cc @jkotas @AndyAyersMS @benaadams

[4creators]

When I designed the API, I thought StaticCast<T, U> means that cast the type to make the static type system happy

IMO bcs not only of the reasons above @fiigii naming is more appealing to C# coders. My first impression with the name is that it does provide casting operations based on static methods and essentially it does that. There is StaticDelegate proposal which implies static, thin, fast delegates and in it's meaning it is close to StaticCast which is also fast (zero op), thin cast. But I could be biased ...

[jkotas]

StaticCast

The equivalent APIs for Span is going to be called just Cast: Span<TTo> Cast<TFrom, TTo>(Span<TFrom> source).

dotnet/coreclr#15941

[sdmaclea]

Sounds like X86 StaticCast<> is a zero op. We definitely need to match. I changed above to StaticCast.

If we should match Span<>.Cast<>, I am happy with that too.

[sdmaclea]

C# does not have pointers to generic types

I change the T* to void*. This could also be Vector64<void>* or something like that.

[sdmaclea]

@eerhardt @CarolEidt @RussKeldorph API-Ready-For-Review?

[eerhardt]

The x86 LoadVector methods are expanded out:

ex.

        public static unsafe Vector128<sbyte> LoadVector128(sbyte* address) { throw null; }
        public static unsafe Vector128<byte> LoadVector128(byte* address) { throw null; }
        public static unsafe Vector128<short> LoadVector128(short* address) { throw null; }
        public static unsafe Vector128<ushort> LoadVector128(ushort* address) { throw null; }
        public static unsafe Vector128<int> LoadVector128(int* address) { throw null; }
        public static unsafe Vector128<uint> LoadVector128(uint* address) { throw null; }
        public static unsafe Vector128<long> LoadVector128(long* address) { throw null; }
        public static unsafe Vector128<ulong> LoadVector128(ulong* address) { throw null; }
        public static unsafe Vector128<double> LoadVector128(double* address) { throw null; }

Same for Sse2.Store.

Why are we using generics and void* here?

[sdmaclea]

Why are we using generics and void* here?

Only to reduce API surface. I am happy to change.

[eerhardt]

I would prefer the two sets of APIs be consistent, unless there is a reason/value for them to be different.

[tannergooding]

I believe in one of the discussions with @CarolEidt, it was determined that we could/should use generics if all 10 numeric types for a method are supported in a single ISA.

x86 doesn't meet this requirement in a number of places, since it generally exposes a subset in one ISA and the rest in the next iteration (e.g. float in Sse, and the other 9 in Sse2, or float and double in Avx, but the other 8 in Avx2).

x86 is using generics in the few places where it does meet the first requirement.

[eerhardt]

OK - that makes sense to me why they are different.

[sdmaclea]

@eerhardt Any reason why this is marked future? I believe this is within range of 2.1. Implementation should take more than a few days.

[sdmaclea]

@eerhardt @CarolEidt @RussKeldorph

These are not currently implemented. I think they their absence will make the Arm64 SIMD intrinsics difficult to use. I think we could safely implement them in CoreCLR and expose the API in CoreFX in time for Zero Bug Bounce.

Is that still an option? Or will the PR's be deferred till after ZBB.

[eerhardt]

If we can't complete simple scenarios with the ARM64 intrinsics APIs, then it doesn't make sense to leave them in. So I'd suggest at least getting a simple end-to-end scenario working, or removing the APIs all together.

Is that still an option?

I would take the PRs to complete a simple end-to-end scenario if they were completed before ZBB.

[terrajobst]

Should the naming reflect alignment requirements?
- LDR doesn't require alignment
- LDX does require alignment

• We probably don't need the static cast as this is just type-system change, so maybe we should just move this to a generic method the vector types.

[tannergooding]

The LoadVector* APIs have already been implemented, we just need to review/approve the surface area.

[terrajobst]

Looks good as proposed, except the namespaces/types should match the existing types:

namespace System.Runtime.Intrinsics.Arm
{
    public partial class AdvSimd 
    {
        public partial class Arm64 : ArmBase
        {
            /// <summary>
            /// Vector load
            ///
            /// Corresponds to vector form of ARM64 LDR
            /// </summary>
            public static unsafe Vector64<T>  LoadVector64<T>(void* address) where T : struct;
            public static unsafe Vector128<T> LoadVector128<T>(void* address) where T : struct;
        
            /// <summary>
            /// Vector store
            ///
            /// Corresponds to vector form of ARM64 STR
            /// </summary>
            public static unsafe void Store<T>(void* address, Vector64<T>  source) where T : struct;
            public static unsafe void Store<T>(void* address, Vector128<T> source) where T : struct;
        }
    }
}