Skip to content
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: autotemps can make stack frame too large #27447

Open
randall77 opened this issue Sep 2, 2018 · 4 comments
Open

cmd/compile: autotemps can make stack frame too large #27447

randall77 opened this issue Sep 2, 2018 · 4 comments
Labels
Milestone

Comments

@randall77
Copy link
Contributor

@randall77 randall77 commented Sep 2, 2018

When the order pass introduces temporaries, it always allocates them on the stack, even if they are too big for the stack.

package main

import "reflect"

func f() {
	g(reflect.TypeOf([2000000000]*byte{}))
}

//go:noescape
func g(p reflect.Type)

We should use the same rules as escape analysis does to decide if we should put the temporary on the stack or the heap.

Before order:

.   .   .   AS2-list
.   .   .   .   NAME-reflect.i a(true) l(1376) x(0) class(PAUTO) tc(1) addrtaken assigned used INTER-interface {}
.   .   .   AS2-rlist
.   .   .   .   CONVIFACE l(6) esc(no) tc(1) implicit(true) INTER-interface {}
.   .   .   .   .   ARRAYLIT l(6) esc(h) tc(1) ARRAY-[2000000000]*byte

After order:

.   AS l(6) tc(1)
.   .   NAME-main..autotmp_5 a(true) l(6) x(0) class(PAUTO) esc(N) tc(1) assigned used ARRAY-[2000000000]*byte
.   .   ARRAYLIT l(6) esc(h) tc(1) ARRAY-[2000000000]*byte

.   AS2 l(6) tc(1)
.   AS2-list
.   .   NAME-reflect.i a(true) l(1376) x(0) class(PAUTO) tc(1) addrtaken assigned used INTER-interface {}
.   AS2-rlist
.   .   CONVIFACE l(6) esc(no) tc(1) implicit(true) INTER-interface {}
.   .   .   NAME-main..autotmp_5 a(true) l(6) x(0) class(PAUTO) esc(N) tc(1) assigned used ARRAY-[2000000000]*byte

.   VARKILL l(6) tc(1)
.   .   NAME-main..autotmp_5 a(true) l(6) x(0) class(PAUTO) esc(N) tc(1) assigned used ARRAY-[2000000000]*byte
@randall77
Copy link
Contributor Author

@randall77 randall77 commented Sep 2, 2018

This is the error:

$ go tool compile tmp2.go
tmp2.go:5:6: stack frame too large (>1GB)
@josharian
Copy link
Contributor

@josharian josharian commented Sep 2, 2018

The cutoff (1<<16) is also duplicated in a couple of places in walk.go (func isSmallMakeSlice, case ONEW in func walkexpr). Should unify all of them.

@cuonglm
Copy link
Contributor

@cuonglm cuonglm commented Apr 6, 2020

@randall77 @josharian @mdempsky How can we make autotemps heap alloc this case? The order happens after escape analysis was done.

@randall77
Copy link
Contributor Author

@randall77 randall77 commented Apr 6, 2020

@cuonglm This can be tricky. On first glance, there's not immediate problem - order can introduce calls to newobject. If the object is pointerless, it works fine. But if the object has pointers, then things that previously didn't escape now do. I think the right, athough difficult, solution would be to treat these heap-allocated things as stack somehow (no write barriers, scanned as part of stack scanning, etc.).
A good first step would be to solve this issue just for pointerless objects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.