JIT: Improve inlining functions with EH in .NET 10

[BruceForstall]

This item tracks work to improve inlining in RyuJIT in .NET 10.

Inline functions containing exception handling (EH)

The JIT currently will not inline a function with exception handling (EH) clauses (try/catch, try/finally, etc.). This work item is to remove that limitation.

A mechanical aspect of the implementation is simply to allow the insertion of the inlinee function EH information into the inliner EH table. Related, the inlinee must create and use its own EH table and not share the root EH table.

One specific note is that we still will not be able to inline any code with EH into an EH filter clause – that is not supported by the runtime. (I think this limitation goes back to Windows SEH, so maybe it can be considered for loosening?)

Specific work:

• Give inlinee compiler its own EH table – don’t share root EH table:
  • JIT: give inlinees their own EH table #112968
• Support inserting inlinee EH table at a specific location in root EH table.
  • This was largely done in JIT: enable cloning of try regions #110020.
• Handle changes in number and nesting of EH clauses:
  • JIT: more inlining with EH prep work #113023
• Stop relying on IL-offset based EH methods outside of the importer:
  • JIT: stop using ehTrueEnclosingTryIndexIL outside of importation #113102
• Modify how the x86-only GT_END_LFIN records the handler nesting depth. Since this value can change as the method is optimized, we now link the GT_END_LFIN to a durable EH region, and use this to look up the region's nesting depth during codegen.
  • JIT: introduce durable EH region ID #113497
• Update inlinee IR with references to new EH table data.
  • JIT: enable inlining methods with EH #112998
• Figure out how to generalize the token-based type reporting in catch clauses to work across token scopes (see note).
• Investigate assertion in CG2 when inlining pinvoke methods with eh:
  • Investigate R2R issue when inlining methods with EH #113742
  • JIT: enable inlining of IL stubs with EH #118140
  • Deferring this to .NET 11, so we can more broadly reconsider IL stub inlining, see JIT: inconsitent logic around inlining pinvoke IL #118220.
• Test and measure performance
  • Testing uncovered a pre-existing issue in cloning lops with EH: JIT: fix issue in cloning loops with trys in handlers #113586
  • For performance we're going to assume the existing inline heuristics are sufficient.
  • Results generally show very good mix in favor of inlining; however, there are some regressions to investigate.
• Look into regressions
  • [Perf] Regressions from Inlining Methods with EH #113913

@SingleAccretion points out that for dynamic methods (which don't have useful tokens) the VM has a mechanism for storing a type handle in the reported EH clause (see SetHasCachedTypeHandle) and it looks like this is queried unconditionally by the code manager. So we should consider using that.

runtime/src/coreclr/vm/jitinterface.cpp

Lines 12684 to 12693 in ed3081f

	if (m_pMethodBeingCompiled->IsDynamicMethod() &&
	((pEHClause->Flags & COR_ILEXCEPTION_CLAUSE_FILTER) == 0) &&
	(clause->ClassToken != mdTokenNil))
	{
	ResolvedToken resolved{};
	m_pMethodBeingCompiled->AsDynamicMethodDesc()->GetResolver()->ResolveToken(clause->ClassToken, &resolved);
	pEHClause->TypeHandle = (void*)resolved.TypeHandle.AsPtr();
	SetHasCachedTypeHandle(pEHClause);
	LOG((LF_EH, LL_INFO1000000, " CachedTypeHandle: 0x%08x -> %p\n", clause->ClassToken, pEHClause->TypeHandle));
	}

Related

#62038

[dotnet-policy-service]

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