You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
func g(x, y *int) {
var a [2]*int
var b = a[:]
b[0] = x
b[1] = y
f(b)
}
The compiler thinks the assignments b[0]=x and b[1]=y need a write barrier because it doesn't know that b points to the stack. If instead we compiled those assignments as a[0]=x and a[0]=y, then the compiler does know that they are on the stack and will elide the write barriers.
Or maybe we could somehow deduce that b always points to the stack? That seems harder.
This problem happens all the time with a ...{}interface, for instance with fmt.Printf args. I'm not sure how much it matters speed-wise, but I suspect this would save a chunk of code size.
Consider the following example:
This gets compiled to something like this:
The compiler thinks the assignments b[0]=x and b[1]=y need a write barrier because it doesn't know that b points to the stack. If instead we compiled those assignments as a[0]=x and a[0]=y, then the compiler does know that they are on the stack and will elide the write barriers.
Or maybe we could somehow deduce that b always points to the stack? That seems harder.
This problem happens all the time with a ...{}interface, for instance with fmt.Printf args. I'm not sure how much it matters speed-wise, but I suspect this would save a chunk of code size.
@RLH @aclements @rsc
The text was updated successfully, but these errors were encountered: