-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[RyuJit] Declaring many vars causes stackspace spilling #7281
Comments
@dotnet/jit-contrib |
Now seeing similar stack size to #7279's example: ; Assembly listing for method T:LotsOfSpans(ref):ubyte
; Lcl frame size = 40
G_M3549_IG01:
4883EC28 sub rsp, 40 |
Still does it using a three field "SpanLike" StackSpace.cs though interestingly dotnet/coreclr#9068 and #7279 have switched output StackSpace.asm |
This sample now reserves and zeros a large amount of stack space it doesn't use
; Lcl frame size = 984
G_M3116_IG01:
57 push rdi
56 push rsi
4881ECD8030000 sub rsp, 984
C5F877 vzeroupper
488BF1 mov rsi, rcx
488DBC24F0000000 lea rdi, [rsp+F0H]
B91E000000 mov ecx, 30
33C0 xor rax, rax
F3AB rep stosd
488BCE mov rcx, rsi
G_M3116_IG02:
4885C9 test rcx, rcx
0F848D020000 je G_M3116_IG46
G_M3116_IG03:
8B4108 mov eax, dword ptr [rcx+8]
83F801 cmp eax, 1
0F8288020000 jb G_M3116_IG47
G_M3116_IG04:
FFC8 dec eax
83F801 cmp eax, 1
0F8287020000 jb G_M3116_IG48 |
In this version the excess stack looks like it is caused by local ref counts being too high. Eg V37 has final ref count of 1 but is actually unreferenced. Let me see if I can spot where the ref counts go wrong. |
The culprit seems to be This method potentially modifies a statement's expression in unspecified ways, so the safe way to handle ref count updates is:
It is likely that the common case is that the tree is unchanged by morphing and this ref count work ends up just burning cycles. Perhaps more motivation for the ideas in dotnet/coreclr#13280. Doing this reduces stack in the new case to 104 bytes. But also triggers asserts as the inflated ref counts may be masking maintenance issues elsewhere. |
There was at least one example where morph directly modifies ref counts (in the "Fixing" this and updating
By and large the big size wins are from smaller local offsets as the stack shrinks down to the used portion. Size increases seem to mainly be from RA changes. Adopting this for real implies a commitment to the current ref count maintenance strategy and will still likely be error prone, though perhaps if we can confine maintenance windows to a select set of higher-level APIs we could get by. |
Full set of jit-diff data from the prospective change. Something odd going on in the trace event code. Will take a closer look.
|
This is fixed |
Optimized code reserves stack space for pre-optimized stack
e.g. The following code reserves 136 bytes of stack, and zeros out 24 bytes (which it uses) even though I'd reason its output and output from https://github.com/dotnet/coreclr/issues/9066 should be identical
Code
Asm produced
category:cq
theme:ref-counts
skill-level:expert
cost:medium
The text was updated successfully, but these errors were encountered: