[mono] Introduce MonoAotMethodSupportedTypesAttribute for generic methods to prevent unnecessary GSHAREDVT fallbacks in the AOT compiler

[ivanpovazan]

Several types in System.Runtime.Intrinsics namespace (for example: Scalar<T>) are defined with struct constraint, but additionally in many places (in different methods) there are runtime checks to check for a specific type support. If the type is not supported the method just throws.
AOTing such pattern with Mono results in unnecessary large and slow methods, especially GSHAREDVT variant (fallback method for any value-type).

In order to avoid generating GSHAREDVT methods introduce a custom attribute which can be attached to methods, for the Scalar<T>::Abs example:

[MonoAotMethodSupportedTypes(new Type[]{ typeof(double), typeof(short),... }, typeof(NotSupportedException))] 
public static T Abs(T value)

MonoAotMethodSupportedTypesAttribute would be then utilized by the AOT compiler at the method's call site.
For example:

• If in the caller, T is known concretely, caller can call the specialized version,
• Otherwise, if the caller doesn't have a concrete T it does a switch on T for the supported types specified by the attribute, calling the specialized versions, or in the default case (as unsupported) would throw exception of the type specified by the attribute.

This way we would eliminate the need for generating GSHAREDVT fallbacks for methods which have the MonoAotMethodSupportedTypesAttribute attached

This is related to #56385

cc @lambdageek @vargaz

[jkotas]

Why is it not possible for the AOT compiler to figure this out by looking at the method code?

[lambdageek]

Why is it not possible for the AOT compiler to figure this out by looking at the method code?

We don't generally look inside the body of a callee when compiling a caller (except when inlining succeeds).

To expand a bit: The idea would be to put this attribute on a callee, and have the caller generate a typeswitch.

---

I'm not super-happy with using an attribute to transfer this information (for a deep callgraph we'd probably need to mark all the nodes with a lot of redundant information). But I can't think of a better approach given our current design

[MichalStrehovsky]

The custom attribute is likely going to take up more space in the executable than an entire GSHAREDVT method body. typeof are very inefficient to encode - they encode a fully qualified type name string with assembly, culture and public key token. A custom attribute blob with 8 types from the System namespace is more than 1 kB in size.

[filipnavara]

The custom attribute is likely going to take up more space in the executable than an entire GSHAREDVT method body.

It can be stripped from the IL after AOT compilation, cannot it? I guess that Android tooling may not be stripping the IL today so it would likely still be valid concern.