-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Utf8Formatter.TryFormat causes massive code bloat when used with a constant StandardFormat #33349
Comments
This change: EgorBo@b7f15b7 makes |
That is still very questionable. Some of the AggressiveInlining in the Utf8Formatter code should be deleted. |
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. |
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. |
The following function compiles to ~900 bytes of code when jitted on x64.
Adding
AggressiveInlining
toStandardFormat.ctor
allows the JIT to reduce theTryFormat
call to a single call toTryFormatUInt64D
, resulting in a code size of less than 100 bytes.The text was updated successfully, but these errors were encountered: