Consider the following example:

//go:noescape
func f(a ...*int)
func g(x, y *int) {
    f(x, y)
}

This gets compiled to something like this:

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.

@RLH @aclements @rsc