[NativeAOT] don't generate __GetFieldHelper if struct has its type (handle?) taken

[NinoFloris]

This is a follow-up on #111544

I've since tested to see whether the delegate fix was enough to remove the rooting of __GetFieldHelper across the affected structs (thanks for doing that work @MichalStrehovsky). Unfortunately it's not, there is a large quantity of them that get their type taken which seems to force __GetFieldHelper to be kept again.

The type is taken by a user defined TypedReference, until the BCL variant is modernized (see #45152 (comment)). After modernization I could use the BCL variant, but it would cause the same rooting.

I really only need the type handle for later validation during AsRef, could we perhaps recognize typeof(T).TypeHandle or typeof(T).TypeHandle.Value as not causing T to become reflectable?

The reason I'm so adamant about this is that __GetFieldHelper generally doubles the size of these small structs in the binary. This creates an unfortunate design trade-off for small structs and classes: get binary bloat or runtime allocations.

[NinoFloris]

I provided my motivation for wanting to use TypedReference in #45152 (comment), I have copied the relevant bits below.

It's a fantastic mechanism for avoiding generic specialization bloat of internal code. Where there is a sizable non-generic spine of code acting on a generic value that - if not for wanting to keep structs unboxed - would just take a callback and object? state (or more commonly won't be modeled to allow for structs at all, opting to refer to some abstract base class instead).

The bloat incurred in those cases is a fundamental problem for using structs in 'open world' api designs. Passing TypedReferences through the internals instead can make structs viable in all dimensions for high perf code, only requiring a cheap indirection to isolate the generic call from the non-generic code.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[MichalStrehovsky]

This is the same problem as described in #116032 (comment).

We only have two ways to refer to types within the compiler right now: type for casting and type for allocation. Type for casting doesn't have reflection metadata and therefore Type.GetTypeFromHandle(typeof(Foo).TypeHandle).Name wouldn't work (should we use the casting version). So we use the allocation version. We need a third way to refer to types.

I briefly looked into this in the past but it's complicated by the fact that RyuJIT doesn't tolerate two ways of referring to a single type so we have to hide it and it gets messy if there's a third form.

[NinoFloris]

Right, understood.

In the case of a TypedReference I actually don't need anything more than the casting version. It's stored for the later call to typedRef.AsRef where the unsafe 'cast' is checked. Essentially there is no way today to stay within the casting metadata if you need a value to store, as it's all casting pattern based.

It's why I hoped we could introduce some pattern based hole. For example getting the IntPtr - furthest away from getting back to Type - such that user code can benefit in some way from the casting metadata. I understand Type.GetTypeFromHandle(RuntimeTypeHandle.FromIntPtr(value)).Name and so on won't work anymore but in this case it's exactly what I need.

It seems 'ok' to do something like that for the IntPtr as it can already fail to resolve on CoreCLR if the type got unloaded. Additionally the api to get back to a type from the IntPtr is also quite new #67090

If not there seems to be no alternative until that large rework happens.

[MichalStrehovsky]

Type.GetTypeFromHandle(RuntimeTypeHandle.FromIntPtr(value)).Name and so on won't work anymore but in this case it's exactly what I need.

This would mean that trim safe and warning free code doesn't work. That goes against our goals and guidance.

I'll try looking into introducing the third MethodTable type within .NET 10 timeframe but I can't make promises.