AOT: analyze trimmed assemblies pre native compilation

[dlosch]

I am looking for a way to analyze the trimmed .NET assemblies pre native compilation (for example for ASP.NET Core apps/csproj). Disclaimer: I thought it was a two step process ... trim, then generate native code.

As far as I can see during the build, PublishTrimmed and PublishAot behave differently/invoke different tasks. Trimmed invokes the ILLink Task, while PublishAOT uses microsoft.dotnet.ilcompiler/ilc.exe to go build output -> obj -> native dll (?).

Would the correct approach be to have a build which outputs trimmed but not native dlls, (unit) test and analyze these assemblies and then perform the AOT during the publish stage (new build)?

As far as I understand, PublishTrimmed invokes the code from https://github.com/dotnet/runtime/tree/main/src/tools/illink/src/linker. Does the ilcompiler do the same?

Thanks for clarification or link to docs. Apologies if I am mixing csproj/msbuild/runtime.

[MichalStrehovsky]

IL level trimming (done with the ILLink) does trimming in a way that assumes the output will be IL again. So often it cannot trim as well as it could if the output wasn't IL. PublishAot uses "trimming" that is built-in to the AOT compiler. One of the tasks of the AOT compiler is to figure out what native code to generate (IL and native code don't have a 1:1 relationship due to things like generics). "Trimming" happens naturally as part of this process: the AOT compiler is not really removing stuff, it's just not generating stuff.

The trimming done by the compiler is not expressible in terms of IL, so you'd not be able to get working assemblies out of it. If you just want to see what is in the output obj file, you can use a tool like sizoscope.

[dlosch]

Thanks for your insight, esp. the link to the sizoscope tool.

Hope a short follow up question is ok ... is there any reliable option to determine which (IL) codepaths ("members") are included in the native binary? I see that most of the members can be traced from the mstat file, but if members get inlined (there may be other ways a member does not appear in the mstat though its code is in the binary), it won't appear in the mstat file.

Thanks again for your insight.

[MichalStrehovsky]

The compiler doesn't track this internally, so it's not possible to see this.

It's possible to approximate this by doing a debug build (dotnet publish -c Debug). The debug build should be pretty much a strict superset of methods/types compiled into release builds and there's no inlining.