Vector<T> operator+ does not generate NotSupportedException on arm32.

[sandreenko]

We are expecting the following test to pass:

    public static int Main()
    {
        var a = new Vector<Vector4>(new Vector4(1));
        try
        {
            a = a + a;
            Debug.Assert(false, "unreachable");
        }
        catch (System.NotSupportedException)
        {
        }
        return 100;
    }

but on arm32 it hits the assert, based on @tannergooding analysis it happens because on arm32 we don't have IsHardwareAccelerated, so we go to the else condition in Vector<T> operator +:
https://source.dot.net/#System.Private.CoreLib/Vector.cs,729
and the else branch is missing something like (in my understanding):

    else
    {
        throw new NotSupportedException(SR.Arg_TypeNotSupported);
    }

https://source.dot.net/#System.Private.CoreLib/Vector.cs,826
similar to the IsHardwareAccelerated block.

cc @CarolEidt

JitDump confirms that we are not doing addition and just generate `default:
Addition.txt

[tannergooding]

CC. @jeffhandley, this is a breaking-change but one we should take as we get two different behaviors based on whether SIMD support is enabled or disabled.

You should also be able to hit this scenario on x86/x64 or ARM64 by setting COMPlus_FeatureSIMD=0.

When IsHardwareAccelerated is false, the operation will just return default as will several of the other operators.

[jeffhandley]

Thanks, @tannergooding. Can you follow our usual process for documenting this as a 5.0 breaking change? And I presume we would not back-port this fix to 3.x; does that match your expectation?

[BruceForstall]

@tannergooding @CarolEidt @sandreenko why would we expect Vector to work? I thought Vector<T> only supported primitive number types T: https://docs.microsoft.com/en-us/dotnet/api/system.numerics.vector-1?view=net-5.0

[tannergooding]

We don't expect it to work, we expect it to throw a NotSupportedException. Today it is "working" and returning a default, but only on platforms or scenarios where IsHardwareAccelerated is returning false

[tannergooding]

As per the above...

Vector<T> is generic and is meant to only support the following 10 primitive types: byte, sbyte, short, ushort, int, uint, long, ulong, float, and double and to throw NotSupportedException for any other generic type.

For the majority of scenarios this is the case, however there are some scenarios such as ARM32 (where hardware acceleration is not supported) or setting COMPlus_FeatureSIMD=0 where a subset of operations return default rather than throwing a NotSupportedException.

We wouldn't bring this for 3.x because:

• It is a breaking change
• We don't have any customers reporting the issue
• The issue should be basically non-existent for platforms supported in 3.x as it requires you to be using ARM32 or to have explicitly disabled the HWAcceleration which is enabled by default on x86, x64, and Arm64

We want to fix this in 5.0 because:

• The existing behavior is inconsistent and goes against the original design goals of the types
• The existing behavior may prevent or make supporting additional types (like half, nint, or nuint) more difficult in the future

CC. @marklio and @PriyaPurkayastha for approval.

[marklio]

This seems reasonable. I'd add a couple of things for framing the impact of the break (correct if I'm wrong):

• The behavior isn't "correct" on arm32, so we're not breaking "working" functionality so much as making unsupported behavior more detectable/diagnosable. (note this doesn't mean it's not a breaking change, just a different class of changes that I think has a lower bar)
• The breaking scenarios are edge case. Either arm32, or "turning off" SIMD. (this is covered in the bullets for why we wouldn't bother fixing it for 3.x, but I think it helps make a case that this isn't very breaking in 5.0)

[tannergooding]

Both points are correct 😄

[BruceForstall]

@tannergooding Should you own this issue?

[tannergooding]

Yes. I've assigned and will work on getting a fix up.