-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Allow inlining for ldsfld + value-type #78736
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsIt turns out that JIT used to always give up on inlining methods with static DateTime Foo { get; } = DateTime.Now;
static DateTime Test() => Foo; Current Tier1 codegen for ; Assembly listing for method Prog:Test():System.DateTime
; Tier-1 compilation
4883EC28 sub rsp, 40
FF159E210E00 call [Prog:get_Foo():System.DateTime]
90 nop
4883C428 add rsp, 40
C3 ret
; Total bytes of code 16 New codegen: ; Assembly listing for method Prog:Test():System.DateTime
; Tier-1 compilation
48B8D6105720E4CCDA88 mov rax, 0x88DACCE4205710D6
C3 ret
; Total bytes of code 11
|
It triggered too many inlinings some of them do not look profitable 😞 will see if I can narrow it down to cases I was interested in |
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
Draft Pull Request was automatically closed for 30 days of inactivity. Please let us know if you'd like to reopen it. |
cf99073
to
c93afc3
Compare
@AndyAyersMS @jakobbotsch PTAL, this PR does two things: First, it slightly relaxes the limitation we had "if we start the actual inlining and meet a static field load/store/addr of a struct type --> reject due to possible helper calls" - I relaxed it with "if field is static readonly and initied - allow". Example: static DateTime Foo { get; } = DateTime.Now;
static DateTime Test() => Foo;
; Assembly listing for method Prog:Test():System.DateTime
; Tier-1 compilation
48B8D6105720E4CCDA88 mov rax, 0x88DACCE4205710D6
C3 ret
; Total bytes of code 11 Second, always allow inlining for cases where we currently give up due to potential helper calls (e.g. TLS field) if we have PGO data and the callsite is hot. [ThreadStatic]
private static int TLS;
static int GetTLS() => TLS;
[MethodImpl(MethodImplOptions.NoInlining)]
static int Test() => GetTLS();
; Assembly listing for method Prog:Test():int
G_M6836_IG01:
sub rsp, 40
G_M6836_IG02:
mov rcx, 0xD1FFAB1E
mov edx, 3
call CORINFO_HELP_GETSHARED_NONGCTHREADSTATIC_BASE_NOCTOR
mov eax, dword ptr [rax+1CH]
G_M6836_IG03:
add rsp, 40
ret
; Total bytes of code 32 Example of a size improvement: https://www.diffchecker.com/XzMrjiah ( jit-diffs (--cctors)
|
Can you run pmi over all the framework assemblies too ( |
This comment was marked as outdated.
This comment was marked as outdated.
@AndyAyersMS ok i've pushed a change and made it conservative:
https://www.diffchecker.com/VOLamS3D/ |
58f79e4
to
378e801
Compare
The main motivation for this is that I need it for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
It turns out that JIT used to always give up on inlining methods with
ldsfld
inside for fields of struct type, e.g:Current Tier1 codegen for
Test
:New codegen: