[mono] Enable AOT compiler to generate a dependency graph of the compiled code

[ivanpovazan]

Motivation

Quite often it is required to understand why a method has been AOTed, which function, type or instantiation caused the compilation of the method and what are its dependencies.

This information is needed when we are trying to answer some of the following questions:

• Why a certain instantiation of a method has been generated?
• Why a certain optimisation has not been performed?
• What are all the wrapper (extra) methods generated by mono for a with a particular method?
• Why is the generated binary so large?
• How much a newly added type impacts the size of the generated binary?
• etc ...

By just disassembling the binary and examining generated symbols, it is quite hard, and sometimes impossible, to answer these kind of questions.

Idea

• Introduce a new feature to the AOT compiler to build a type/call dependency graph by recording when for example:

  • a method calls another method
  • a method instantiates a type
  • a method requires a runtime wrapper(s) - with a reason (eg: interpreter requires gsharedvt_out wrappers in order to call AOTed code)
  • ...

• The dependency information should be logged into a file in a well-known graph description language for example:

  • DOT-graphviz
  • DGML-MS

• The feature should be controlled by a command-line switch.

Benefits

The generated dependency graphs would:

• Help us understand and visualize why a specific type or a method has been generated
• Reduce the time that takes to discover the cause of an issue (improve debugging)
• Enable further analysis for potential improvements of the generated code (code size reduction)
• Help us discover problems with the AOTed code.

---

This is merely an idea for the improvement, not an official proposal, making this issue open for discussions and ideas.

CC: @lambdageek @vargaz

[fanyang-mono]

It would be nice to have a simpler version of this feature, which prints out a list of AOT compiled methods for il strip tool to consume. That feature would help with stripping IL's for MAUI Android apps, which used Profiled AOT mode. (#44855)

[fanyang-mono]

It would be nice to have a simpler version of this feature, which prints out a list of AOT compiled methods for il strip tool to consume. That feature would help with stripping IL's for MAUI Android apps, which used Profiled AOT mode. (#44855)

Created a separated issue for this #79551

[ivanpovazan]

Implementing this feature has been paused for now, as we are trying to prove whether it is possible to use NativeAOT's dependency analysis to drive MonoAOT compilation in order to reduce the generated code size (especially in case of generics): #80941

[ivanpovazan]

Moving to 9.0.0