-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
cmd/compile: compiler stores a stack pointer into a global object #61730
Comments
Additional information: in Go1.17.7, I notice that all arrays are allocated on heap, which follows the two invariants of escape analysis. The following assembly code is generated by Go1.17.7, allocating array
But in Go1.18, all arrays are allocated on the stack as the following assembly code.
Go1.19.5 and Go1.20.6 share the above pattern, allocating all arrays on stack. And I notice that in Go 1.18 Release Notes, "The garbage collector now includes non-heap sources of garbage collector work". Does the change of GC in Go1.18 affect the strategy of allocating small array? |
This looks like:
I think the compiler is trying to cache the allocations of the static slice literals however it also for some reason it does not generate the code to do anything with the cached slices, it always recreates on each iteration even if you leak them on purpose. That is if anything a performance bug, since this creates a bunch of writes into globals which add writebarriers for no reason. I'm not sure why the compiler is somehow deciding it should generate caches but not use them. |
Minimized:
|
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes, I can reproduce in go1.20.7 linux/amd64
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I use go1.20.5 to compile the following code:
In the generated SSA and assembly code, I notice that the Go compiler generates some instructions that store a stack pointer(point to the stack-allocated array) into a global slice header.
Just like the assembly code below, the MOV instruction at 0x4585bf stores a stack pointer into a global object:
I have read the comments in slicelit, but I didn't find any operations that can generate such stores. As far as I know, pointers to stack objects cannot be stored in global objects. So is this a compiler bug? Or the Go compiler does this on purpose to achieve some optimization I don't know yet?
note: this is originally posted on golang-nuts
Thanks
What did you expect to see?
The stack pointer is not stored into any global object.
What did you see instead?
The stack pointer is stored into a global object.
The text was updated successfully, but these errors were encountered: