]> Cypherpunks repositories - gostls13.git/commit
cmd/compile: reorder how slicelit initializes a slice
authorKeith Randall <khr@golang.org>
Sun, 24 Apr 2016 05:59:01 +0000 (22:59 -0700)
committerKeith Randall <khr@golang.org>
Sun, 24 Apr 2016 18:15:41 +0000 (18:15 +0000)
commit934c3599648ae841668ec753881134347fc28c29
treedf3cd69d7126192c1d5b6cf09b790645207d56dd
parentc4c182140adedf300800778127840e3b8b9f7423
cmd/compile: reorder how slicelit initializes a slice

  func f(x, y, z *int) {
    a := []*int{x,y,z}
    ...
  }

We used to use:
  var tmp [3]*int
  a := tmp[:]
  a[0] = x
  a[1] = y
  a[2] = z

Now we do:
  var tmp [3]*int
  tmp[0] = x
  tmp[1] = y
  tmp[2] = z
  a := tmp[:]

Doesn't sound like a big deal, but the compiler has trouble
eliminating write barriers when using the former method because it
doesn't know that the slice points to the stack.  In the latter
method, the compiler knows the array is on the stack and as a result
doesn't emit any write barriers.

This turns out to be extremely common when building ... args, like
for calls fmt.Printf.

Makes go binaries ~1% smaller.

Doesn't have a measurable effect on the go1 fmt benchmarks,
unfortunately.

Fixes #14263
Update #6853

Change-Id: I9074a2788ec9e561a75f3b71c119b69f304d6ba2
Reviewed-on: https://go-review.googlesource.com/22395
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
src/cmd/compile/internal/gc/sinit.go
src/cmd/compile/internal/gc/walk.go
test/writebarrier.go