Utf8Formatter.TryFormat causes massive code bloat when used with a constant StandardFormat

[Thealexbarney]

The following function compiles to ~900 bytes of code when jitted on x64.

private static bool Format(Span<byte> span, int value)
{
 return Utf8Formatter.TryFormat(value, span, out _, new StandardFormat('D', 2));
}

Adding AggressiveInlining to StandardFormat.ctor allows the JIT to reduce the TryFormat call to a single call to TryFormatUInt64D, resulting in a code size of less than 100 bytes.

[EgorBo]

This change: EgorBo@b7f15b7

makes StandardFormat.ctor inlineable 😄 (removes a branch+bb basically)
(And it seems it does make sense to make it so since it's mostly used with constant arguments)

[jkotas]

TryFormatUInt64D, resulting in a code size of less than 100 bytes

That is still very questionable. Some of the AggressiveInlining in the Utf8Formatter code should be deleted.

[GrabYourPitchforks]

I agree that some of the AggressiveInlining attributes should disappear. The tricks I was playing around with over at #32843 and Andy's WIP PR should also be generally applicable here, which could further reduce the codegen size around the switch statement.

[Thealexbarney]

Ideally all the dispatch code in TryFormatUInt64/TryFormatInt64 would disappear if the format was a constant. AggressiveInlining can't differentiate between the case of using a constant or not, so the entire TryFormatUInt64 function would always be inlined in non-constant cases.

I'd say that TryFormatUInt64Default should definitely not have AggressiveInlining if TryFormatUInt64 also has AggressiveInlining. TryFormatUInt64Default's child functions should keep AggressiveInlining since they would be inlined twice at most throughout the entire program.