[mono] Generate valid LLVM IR for vectors with unsupported element types

[imhameed]

Before this change, vectors with unsupported element types generated generic
"value type" code, which can cause invalid IR to be generated when compiling
System.Runtime.Intrinsics.WithLower<bool> on arm64. For posterity, here's the
relevant part of WithLower:

        public static Vector128<T> WithLower<T>(this Vector128<T> vector, Vector64<T> value)
            where T : struct
        {
            if (AdvSimd.IsSupported)
            {
                return AdvSimd.InsertScalar(vector.AsUInt64(), 0, value.AsUInt64()).As<ulong, T>();
            }
            ...

Vector128.As is currently implemented as an intrinsic that emits a bitcast,
but the Vector128<bool> and Vector64<bool> parameters are never explicitly
loaded from a pair of GPRs into vectors in the function prologue.

Before this change, WithLower<bool> generates:

define dso_local monocc i128 @"System.Runtime.Intrinsics.Vector128:WithLower<bool> (System.Runtime.Intrinsics.Vector128`1<bool>,System.Runtime.Intrinsics.Vector64`1<bool>)"([2 x i64] %arg_vector, [1 x i64] %arg_value) #0 gc "coreclr" {
BB0:
  %0 = bitcast [2 x i64] %arg_vector to <2 x i64>
  %1 = bitcast [1 x i64] %arg_value to i64
  %xinsert = insertelement <2 x i64> %0, i64 %1, i32 0
  %2 = bitcast <2 x i64> %xinsert to i128
  %3 = load i8 (i64*, i64*)*, i8 (i64*, i64*)** @"[tramp_6039] System.Type:op_Inequality (System.Type,System.Type)", align 8
  %4 = load i64, i64* inttoptr (i64 281473683542664 to i64*)
  %5 = icmp eq i64 %4, 0
  br i1 %5, label %gc.safepoint_poll.exit, label %gc.safepoint_poll.poll.i, !prof !1
  ...

The two bitcasts from arrays to first-class types are invalid. This would cause
an assertion failure if Mono is linked against a copy of LLVM built with
assertions enabled. With assertions disabled, this eventually causes opt/llc to
crash. This change works around this by generating undef values on function
entry for parameters that have SIMD-with-invalid-element types and associating
these dummy values to the mini IR registers that would be consumed by any
subsequent SIMD operations.

Future work:

FullAOT tests should be resurrected in dotnet/runtime.

The interaction between gsharedvt and SIMD types should be clarified.

[imhameed]

The runtime-staging failures look relevant.

[vargaz]

metadata/ code should not include mini.h, this should be done some other way.

[imhameed]

I also think this wouldn't completely fix Full AOT on arm64 because System.Runtime.Intrinsics.WithLower will be instantiated with T_GSHAREDVT, leading to exactly the same problem this was intended to fix; will check now and think about this a little more

[vargaz]

Maybe it can check klass->simd_type && mini_is_gsharedvt_type (..) in the jit, and fail gsharedvt, using GSHAREDVT_FAILURE ().

[imhameed]

Tried another approach.

[tannergooding]

Why is the LLVM IR generated not simply the IL when the type isn't supported?

All of Vector<T> and Vector64/128/256<T> have some sort of IL that defines the "correct" behavior when an "unsupported" type is encountered and that is almost always throw new NotSupportedException()

I'd expect that the same happen here and so the LLVM IR should never get any vector IR for something like Vector<bool>.
-- For reference the supported types today are only: byte, sbyte, short, ushort, int, uint, long, ulong, double, and float (the 10 "core" primitive types).
-- Vector<T> also supports nint and nuint in .NET 6, support for these on Vector64/128/256<T> is approved but NYI
-- All other types should currently throw

[imhameed]

Why is the LLVM IR generated not simply the IL when the type isn't supported?

All of Vector<T> and Vector64/128/256<T> have some sort of IL that defines the "correct" behavior when an "unsupported" type is encountered and that is almost always throw new NotSupportedException()

... Oh man. Thanks for the sanity check.

#53707