-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mono] Introduce MonoAotMethodSupportedTypesAttribute for generic methods to prevent unnecessary GSHAREDVT fallbacks in the AOT compiler #71431
Comments
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 |
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. |
Moving to 9.0.0 |
Several types in
System.Runtime.Intrinsics
namespace (for example:Scalar<T>
) are defined withstruct
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 theScalar<T>::Abs
example:MonoAotMethodSupportedTypesAttribute
would be then utilized by the AOT compiler at the method's call site.For example:
This way we would eliminate the need for generating
GSHAREDVT
fallbacks for methods which have theMonoAotMethodSupportedTypesAttribute
attachedThis is related to #56385
cc @lambdageek @vargaz
The text was updated successfully, but these errors were encountered: