Split TryGetGenericMethodComponents into two overloads

[MichalStrehovsky]

Resolves#83069. Hello World is now 1.45 MB, down from 1.65 MB.

Half of the callers don't care about the MethodNameAndSignature part - don't spend time computing it.

This also allows trimming MethodNameAndSignature from a hello world, which allows trimming pretty much all of the type loader.

Cc @dotnet/ilc-contrib

[ghost]

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

Issue Details

---

Resolves #83069. Hello World is now 1.45 MB, down from 1.65 MB.

Half of the callers don't care about the MethodNameAndSignature part - don't spend time computing it.

This also allows trimming MethodNameAndSignature from a hello world, which allows trimming pretty much all of the type loader.

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jkotas]

Nice!

[MichalStrehovsky]

Hm, we still have the type loader on Linux. At least two reasons:

1. ConsolePal uses a multi-dim array on Linux and multi-dim array construction has this piece of code to handle a dumb IL-level corner case.

   runtime/src/coreclr/nativeaot/System.Private.CoreLib/src/Internal/Runtime/CompilerHelpers/ArrayHelpers.cs

   Lines 63 to 69 in d0d7154

   	if(rank==1)
   	{
   	// Multidimensional array of rank 1 with 0 lower bounds gets actually allocated
   	// as an SzArray. SzArray is castable to MdArray rank 1.
   	TypeelementType=Type.GetTypeFromHandle(newRuntimeTypeHandle(eeType.ArrayElementType))!;
   	returnRuntimeImports.RhNewArray(elementType.MakeArrayType().TypeHandle.ToEETypePtr(),pDimensions[0]);
   	}

   
   MakeArrayType needs the type loader in theory. (In practice, the MethodTable for this was created by the compiler, we just need to find it in a hashtable. Still annoying though.)
2. This one is really annoying:
   
   Boils down to "we have a delegate to something that takes something with a ValueTuple over a reference type, which means we need to make the target reflectable, which means we need a type loader template for all the arguments and the template needs the equality comparer infrastructure for the cctor". This is what I was trying to "fix" in Limit impact of reflectable Invoke methods #83066 but then it went away on its own on Windows (the delegate is a SpanAction so it would conveniently go away).

[MichalStrehovsky]

In practice, the MethodTable for this was created by the compiler, we just need to find it in a hashtable.

Ah, nope. We could still be in some shared code and the MdArray handle was template-type-loaded. So we might need to template-type-load the SzArray.

We'll have to live with this.

I'll update the Linux baseline size to not expect the template type loader saving.

[jkotas]

Ah, nope. We could still be in some shared code and the MdArray handle was template-type-loaded. So we might need to template-type-load the SzArray.

We can teach the JIT to use a different JIT helper for MD arrays that have rank 2 or more. The JIT helper for this case would not have this dependency.

[jkotas]

This one is really annoying:

We can fix this one by calling FastAllocateString directly. We are calling FastAllocateString directly in System.Globalization in number of places, so one more is not a big deal.

[MichalStrehovsky]

We can teach the JIT to use a different JIT helper for MD arrays that have rank 2 or more. The JIT helper for this case would not have this dependency.

I was afraid you would suggest this :).

This one is really annoying:

We can fix this one by calling FastAllocateString directly. We are calling FastAllocateString directly in System.Globalization in number of places, so one more is not a big deal.

Another alternative would be delaying making the delegate targets reflectable: #82607 (comment). But FastAllocateString is even more savings.