Support precompiling fast type switches in ILC cctor interpreter (Native AOT)

[Sergio0694]

Note

Related to dotnet/csharplang#356, but just for ILC support to restrict scope.

As part of the sidecar .dll for CsWinRT 3.0 (see tracking issue), we'll be generating a lookup table for all IDIC implementations for the application domain. This has to be in the sidecar .dll because it allows us to have a single entry point from which to gather all IDIC implementations across all referenced assemblies, as well as all generic IDIC implementations, which necessarily have to be generated as part of the sidecar .dll, to properly support all the other AOT optimizations we're planning to have (eg. vtable folding).

We'll be emitting something similar to this (made up names for now):

public static class DynamicInterfaceCastableLookup
{
    public static Type? GetInterfaceImplementation(Type type)
    {
        if (type == typeof(IFoo)) return typeof(IFooImpl);
        if (type == typeof(IBar)) return typeof(IBarImpl);
        if (type == typeof(IBaz)) return typeof(IBazImpl);
        // ...
        return null;
    }
}

We expect this to end up having several hundred types (if not thousands), since it includes:

• All IDIC interfaces across all referenced projections (including the Windows SDK projections)
• All constructed IDIC interfaces for discovered generic instantiations

In order for this to be practical, we'd need some guarantees from ILC:

• All key-value pairs in this lookup method should be fully trimmable
• ILC should be able to pre-initialize this into a fast lookup in the FOH

Note that because this is in the sidecar .dll, we can generate any IL pattern we need.
So it's completely fine for us to emit code with whatever pattern required to make ILC's life simpler.

@MichalStrehovsky mentioned the first point (trimmability) should already be there. So this issue is to track pre-initialization.

Is there a way to special case some pattern we can rely on in our sidecar .dll, to enable pre-initialization?

[dotnet-policy-service]

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

[jkotas]

ILC should be able to pre-initialize this into a fast lookup in the FOH

This sort of fast type mapping is what the type map feature was meant for.

[Sergio0694]

Just so I understand, are you saying we could piggyback on the type map for this scenario too in some way? Would this be eg. using the proxy type mapping with some other type map group just for IDIC impl mapping, or something else? 🤔

(I also didn't realize the proxy map would work for interface types as keys at all, as my understanding was entries would be kept only for "allocated" types)

[jkotas]

Would this be eg. using the proxy type mapping with some other type map group just for IDIC impl mapping

Yes, that was the idea.

I also didn't realize the proxy map would work for interface types as keys at all, as my understanding was entries would be kept only for "allocated" types

Hmmm, good point. I am not sure whether it would work for interfaces.

I think my meta point is that we should make the same type mapping pattern work reasonably well for both NAOT and non-NAOT. We do not want to end up in a situation where the patterns needed for efficient (O(1) or O(long N)) type mapping are completely different for NAOT and non-NAOT.

[Sergio0694]

I also have another potential concern: talking with @MichalStrehovsky he mentioned that the linker has some special casing for all [DynamicInterfaceCastableImplementation] types, where as soon as you just do typeof(T) on any of them, it'll just consider the whole thing as rooted. If we do want to go this way (reusing the type proxy map), we should also double check that doing typeof(FooImpl) in the attribute argument doesn't accidentally end up marking all those impl types as rooted 🤔

So I suppose this, and whether it's valid to use interface types as keys, and what semantics does that imply in that case.

Other than that, if we can figure this out, using the type proxy map sounds good for us, we could definitely do this 🙂

[Sergio0694]

@sbomer do you have any thoughts on this? Is this a scenario you think the linker/ILC could accomodate? If it helps, in this case all values in this table would have [IDynamicInterfaceCastableImplementation], in case that lets you narrow the scope at all.

[MichalStrehovsky]

If checks with typeof should already be trimmed with native AOT. I don't think they are trimmed with ILLinker if PublishTrimmed matters.

When you say preinitialize, what do you mean? If it's "understanding as part of static constructor interpreter", this already works as of .NET 9:

class Program
{
    static readonly Type t1;
    static readonly Type t2;

    static Program()
    {
        t1 = Grab(typeof(object));
        t2 = Grab(typeof(Enum));
    }

    static Type Grab(Type t)
    {
        if (t == typeof(object))
            return typeof(string);
        if (t == typeof(Enum))
            return typeof(ValueType);
        return null;
    }

    static void Main()
    {
        Console.WriteLine(t1);
        Console.WriteLine(t2);
    }
}

Main will compile into:

00007FF7168AB130  sub         rsp,28h  
00007FF7168AB134  lea         rcx,[__RuntimeType_String (07FF71698E990h)]  
00007FF7168AB13B  call        System_Console_System_Console__WriteLine_11 (07FF716871EA0h)  
00007FF7168AB140  lea         rcx,[__RuntimeType_S_P_CoreLib_System_ValueType (07FF71698E9B0h)]  
00007FF7168AB147  call        System_Console_System_Console__WriteLine_11 (07FF716871EA0h)  
00007FF7168AB14C  nop  
00007FF7168AB14D  add         rsp,28h  
00007FF7168AB151  ret  

If you mean "build an efficient representation of the method body so that it can execute quickly" instead, this is basically a request for #12260. Typeswitch doesn't have to be a new IL instruction, it could also be a pattern match, but it is a codegen feature request.

talking with @MichalStrehovsky he mentioned that the linker has some special casing for all [DynamicInterfaceCastableImplementation] types, where as soon as you just do typeof(T) on any of them

To be more precise, the compiler considers all typeof(T) of something that is DynamicInterfaceCastableImplementation as returned from IDynamicInterfaceCastable.GetInterfaceImplementation. There are some exception like when the compiler can prove the typeof doesn't escape (e.g. it is used in a == comparison).

[Sergio0694]

"When you say preinitialize, what do you mean?"

In this context I meant "precompile the whole switch into a fast frozen lookup table". Basically exactly like the proxy type map. We're going to have probably over 1000 types in this lookup, so chances are if we just used a method, the body would end up being so big that the JIT would just give up and end up disabling all optimizations. We're already hitting this issue in our "type hierarchy" lookup, which is basically analogous but just with a string -> string lookup.

I do like the idea of reusing the proxy type map, since that will:

• Be decently fast on CoreCLR too
• ILC will already have the logic to turn it into a fast frozen lookup

It seems to me we just need to make sure that:

• Using interface types as keys is valid and will work correctly
• Using [IDynamicInterfaceCastableImplementation] types as values doesn't accidentally root them (might need special casing?)

@MichalStrehovsky @sbomer is this something we could do?