Navigation Menu

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

Jump to bottom

cmd/compile: treat strings as constant for initialization #18637

Closed
randall77 opened this issue Jan 12, 2017 · 3 comments
Closed

cmd/compile: treat strings as constant for initialization #18637

randall77 opened this issue Jan 12, 2017 · 3 comments
Labels
FrozenDueToAge Performance
Milestone
Go1.9

Comments

@randall77
Copy link
Contributor 

type T struct {
	x   int
	pad [7]int
}
type U struct {
	x   int
	y   string
	pad [5]int
}
func f(t *T) {
	*t = T{x: 7}
}
func g(u *U) {
	*u = U{x: 7}
}

For f we set *t by just doing a copy from a global constant.
For g we first allocate a temporary on the stack, initialize it, then copy it to the result.

There's no need for g to allocate a stack temporary. The initializing value, even if y is a non-empty string constant, is constant. We could do just like f does and build a global constant for the initializer. (g needs to use typedmemmove instead of duffcopy because it needs a write barrier, at least with the new hybrid barriers.)

See also #18636. Even for f maybe we should probably write/zero fields directly instead of copying.
@randall77 randall77 added this to the Go1.9 milestone Jan 12, 2017
@mdempsky
Copy link
Member

I think "strings" here is a red herring. I believe the issue is just that the value contains pointers. For example, we generate identical code if you change the definition of U to:

type U struct {
    x int
    y *byte
    pad [6]int
}

@mdempsky
Copy link
Member

The extra stack copy comes from here: https://github.com/golang/go/blob/9c066ba/src/cmd/compile/internal/gc/order.go#L414

Simply removing that entire chunk (lines 414--423) eliminates the stack copy so that we just typedmemmove directly from static data.

We used to need that code because removing it caused net/http to become flaky (see review discussion on CL 21242). I vaguely recall a couple weeks ago looking at this again, and finding that it wasn't necessary anymore since some other CL (maybe c39918a?). I didn't establish a good confidence about why it's not necessary anymore though. (Of course, I have no confidence about why it used to be necessary either.)

@randall77
Copy link
Contributor Author

This is now fixed. Not sure what did it, but we copy directly from a statictemp now.

@golang golang locked and limited conversation to collaborators May 31, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Performance
Projects
None yet
Milestone
Go1.9
Development

No branches or pull requests
3 participants
@mdempsky @randall77 @gopherbot