go/src/cmd/compile/internal/ssa/schedule.go

230 lines
6.2 KiB
Go
Raw Normal View History

// Copyright 2015 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package ssa
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
import "container/heap"
const (
ScorePhi = iota // towards top of block
ScoreVarDef
ScoreMemory
ScoreDefault
ScoreFlags
ScoreControl // towards bottom of block
)
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
type ValHeap struct {
a []*Value
less func(a, b *Value) bool
}
func (h ValHeap) Len() int { return len(h.a) }
func (h ValHeap) Swap(i, j int) { a := h.a; a[i], a[j] = a[j], a[i] }
func (h *ValHeap) Push(x interface{}) {
// Push and Pop use pointer receivers because they modify the slice's length,
// not just its contents.
v := x.(*Value)
h.a = append(h.a, v)
}
func (h *ValHeap) Pop() interface{} {
old := h.a
n := len(old)
x := old[n-1]
h.a = old[0 : n-1]
return x
}
func (h ValHeap) Less(i, j int) bool { return h.less(h.a[i], h.a[j]) }
// Schedule the Values in each Block. After this phase returns, the
// order of b.Values matters and is the order in which those values
// will appear in the assembly output. For now it generates a
// reasonable valid schedule using a priority queue. TODO(khr):
// schedule smarter.
func schedule(f *Func) {
// For each value, the number of times it is used in the block
// by values that have not been scheduled yet.
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
uses := make([]int32, f.NumValues())
// "priority" for a value
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
score := make([]int8, f.NumValues())
// scheduling order. We queue values in this list in reverse order.
var order []*Value
// maps mem values to the next live memory value
nextMem := make([]*Value, f.NumValues())
// additional pretend arguments for each Value. Used to enforce load/store ordering.
additionalArgs := make([][]*Value, f.NumValues())
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
for _, b := range f.Blocks {
// Compute score. Larger numbers are scheduled closer to the end of the block.
for _, v := range b.Values {
switch {
case v.Op == OpAMD64LoweredGetClosurePtr:
// We also score GetLoweredClosurePtr as early as possible to ensure that the
// context register is not stomped. GetLoweredClosurePtr should only appear
// in the entry block where there are no phi functions, so there is no
// conflict or ambiguity here.
if b != f.Entry {
f.Fatalf("LoweredGetClosurePtr appeared outside of entry block, b=%s", b.String())
}
score[v.ID] = ScorePhi
case v.Op == OpPhi:
// We want all the phis first.
score[v.ID] = ScorePhi
case v.Op == OpVarDef:
// We want all the vardefs next.
score[v.ID] = ScoreVarDef
case v.Type.IsMemory():
// Schedule stores as early as possible. This tends to
// reduce register pressure. It also helps make sure
// VARDEF ops are scheduled before the corresponding LEA.
score[v.ID] = ScoreMemory
case v.Type.IsFlags():
// Schedule flag register generation as late as possible.
// This makes sure that we only have one live flags
// value at a time.
score[v.ID] = ScoreFlags
default:
score[v.ID] = ScoreDefault
}
}
}
for _, b := range f.Blocks {
// Find store chain for block.
// Store chains for different blocks overwrite each other, so
// the calculated store chain is good only for this block.
for _, v := range b.Values {
if v.Op != OpPhi && v.Type.IsMemory() {
for _, w := range v.Args {
if w.Type.IsMemory() {
nextMem[w.ID] = v
}
}
}
}
// Compute uses.
for _, v := range b.Values {
if v.Op == OpPhi {
// If a value is used by a phi, it does not induce
// a scheduling edge because that use is from the
// previous iteration.
continue
}
for _, w := range v.Args {
if w.Block == b {
uses[w.ID]++
}
// Any load must come before the following store.
if v.Type.IsMemory() || !w.Type.IsMemory() {
continue // not a load
}
s := nextMem[w.ID]
if s == nil || s.Block != b {
continue
}
additionalArgs[s.ID] = append(additionalArgs[s.ID], v)
uses[v.ID]++
}
}
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
if b.Control != nil && b.Control.Op != OpPhi {
// Force the control value to be scheduled at the end,
// unless it is a phi value (which must be first).
score[b.Control.ID] = ScoreControl
// Schedule values dependent on the control value at the end.
// This reduces the number of register spills. We don't find
// all values that depend on the control, just values with a
// direct dependency. This is cheaper and in testing there
// was no difference in the number of spills.
for _, v := range b.Values {
if v.Op != OpPhi {
for _, a := range v.Args {
if a == b.Control {
score[v.ID] = ScoreControl
}
}
}
}
}
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
// To put things into a priority queue
// The values that should come last are least.
priq := &ValHeap{
a: make([]*Value, 0, 8), // TODO allocate once and reuse.
less: func(x, y *Value) bool {
sx := score[x.ID]
sy := score[y.ID]
if c := sx - sy; c != 0 {
return c > 0 // higher score comes later.
}
if x.Line != y.Line { // Favor in-order line stepping
return x.Line > y.Line
}
if x.Op != OpPhi {
if c := len(x.Args) - len(y.Args); c != 0 {
return c < 0 // smaller args comes later
}
}
return x.ID > y.ID
},
}
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
// Initialize priority queue with schedulable values.
for _, v := range b.Values {
if uses[v.ID] == 0 {
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
heap.Push(priq, v)
}
}
// Schedule highest priority value, update use counts, repeat.
order = order[:0]
for {
// Find highest priority schedulable value.
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
// Note that schedule is assembled backwards.
if priq.Len() == 0 {
break
}
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
v := heap.Pop(priq).(*Value)
// Add it to the schedule.
order = append(order, v)
// Update use counts of arguments.
for _, w := range v.Args {
if w.Block != b {
continue
}
uses[w.ID]--
if uses[w.ID] == 0 {
// All uses scheduled, w is now schedulable.
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
heap.Push(priq, w)
}
}
for _, w := range additionalArgs[v.ID] {
uses[w.ID]--
if uses[w.ID] == 0 {
// All uses scheduled, w is now schedulable.
cmd/compile: Tinkering with schedule for debug and regalloc This adds a heap-based proper priority queue to the scheduler which made a relatively easy to test quite a few heuristics that "ought to work well". For go tools themselves (which may not be representative) the heuristic that works best is (1) in line-number-order, then (2) from more to fewer args, then (3) in variable ID order. Trying to improve this with information about use at end of blocks turned out to be fruitless -- all of my naive attempts at using that information turned out worse than ignoring it. I can confirm that the stores-early heuristic tends to help; removing it makes the results slightly worse. My metric is code size reduction, which I take to mean fewer spills from register allocation. It's not uniform. Here's the endpoints for "vet" from one set of pretty-good heuristics (this is representative at least). -2208 time.parse 13472 15680 -14.081633% -1514 runtime.pclntab 1002058 1003572 -0.150861% -352 time.Time.AppendFormat 9952 10304 -3.416149% -112 runtime.runGCProg 1984 2096 -5.343511% -64 regexp/syntax.(*parser).factor 7264 7328 -0.873362% -44 go.string.alldata 238630 238674 -0.018435% 48 math/big.(*Float).round 1376 1328 3.614458% 48 text/tabwriter.(*Writer).writeLines 1232 1184 4.054054% 48 math/big.shr 832 784 6.122449% 88 go.func.* 75174 75086 0.117199% 96 time.Date 1968 1872 5.128205% Overall there appears to be an 0.1% decrease in text size. No timings yet, and given the distribution of size reductions it might make sense to wait on those. addr2line text (code) = -4392 bytes (-0.156273%) api text (code) = -5502 bytes (-0.147644%) asm text (code) = -5254 bytes (-0.187810%) cgo text (code) = -4886 bytes (-0.148846%) compile text (code) = -1577 bytes (-0.019346%) * changed cover text (code) = -5236 bytes (-0.137992%) dist text (code) = -5015 bytes (-0.167829%) doc text (code) = -5180 bytes (-0.182121%) fix text (code) = -5000 bytes (-0.215148%) link text (code) = -5092 bytes (-0.152712%) newlink text (code) = -5204 bytes (-0.196986%) nm text (code) = -4398 bytes (-0.156018%) objdump text (code) = -4582 bytes (-0.155046%) pack text (code) = -4503 bytes (-0.294287%) pprof text (code) = -6314 bytes (-0.085177%) trace text (code) = -5856 bytes (-0.097818%) vet text (code) = -5696 bytes (-0.117334%) yacc text (code) = -4971 bytes (-0.213817%) This leaves me sorely tempted to look into a "real" scheduler to try to do a better job, but I think it might make more sense to look into getting loop information into the register allocator instead. Fixes #14577. Change-Id: I5238b83284ce76dea1eb94084a8cd47277db6827 Reviewed-on: https://go-review.googlesource.com/20240 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2016-03-04 14:19:49 -05:00
heap.Push(priq, w)
}
}
}
if len(order) != len(b.Values) {
f.Fatalf("schedule does not include all values")
}
for i := 0; i < len(b.Values); i++ {
b.Values[i] = order[len(b.Values)-1-i]
}
}
f.scheduled = true
}