Definitely Future milestone - just wanted to write down a couple notes as I spent a couple hours looking at this today.

Optimized compilation in NativeAOT consists of two phases - scanning (builds whole program view) and compilation (generates code).

Scanning is currently implemented in C# - we have an IL importer that essentially simulates some things that RyuJIT will need when compiling the method (e.g. method call will require us to provide method body of the callee, etc.).

We discussed a couple times doing this analysis with RyuJIT and there even was a prototype that didn't quite do what we need in NativeAOT (it collected whole program view for RyuJIT's purposes, but not ours, so it's not very useful for NativeAOT - what we need is the list of relocs from a method body).

I put together a hack to let us run RyuJIT as a scanner: MichalStrehovsky@34f7a96

This hack does nothing to prevent codegen, so we do all the unnecessary things like register allocation and code generation in RyuJIT and then we throw it all away. The compile throughput impact is about 15%.

It is a regression in size, both for BasicMinimalApi (10%) and HelloWorld (5%). I expect it also to regress working set as a side effect.

Observations:

• We don't have a good way to model optimizations we currently do in scanner through JitInterface (e.g. someType.GetType() == typeof(X) currently avoids requesting a MethodTable with a populated vtable in the C# scanner, but RyuJIT can't communicate a limited MethodTable is sufficient - we get a full one).
• Fix VNs for method table fetched from newobj runtimelab#1128 shows up as a problem again because we want to be able to give out MethodTable symbols without a vtable
• RyuJIT may optimize away some things during importing around virtual method lookups, or generic dictionary lookup, but then during compilation it's going to ask questions about those that we cannot answer (this structurally falls out from JitInterface design where getCallinfo provides some information that RyuJIT may optimize into something that doesn't need the thing JitInterface provided).

Not sure if all of the size regression can be attributed to above - the above causes enough noise that it wasn't worth spending more time on it.