mirror of https://github.com/golang/go.git
cmd/compile/internal/gc: update comment in plive.go
onebitwalktype1 no longer appears to be a bottleneck for the mentioned test case. In fact, we appear to compile it significantly faster now than Go 1.4 did (~1.8s vs ~3s). Fixes #21951. Change-Id: I315313e906092a7d6ff4ff60a918d80a4cff7a7f Reviewed-on: https://go-review.googlesource.com/65110 Reviewed-by: Keith Randall <khr@golang.org>
This commit is contained in:
parent
1eacf78858
commit
93e97ef066
|
|
@ -351,10 +351,9 @@ func (lv *Liveness) blockEffects(b *ssa.Block) *BlockEffects {
|
|||
return &lv.be[b.ID]
|
||||
}
|
||||
|
||||
// NOTE: The bitmap for a specific type t should be cached in t after the first run
|
||||
// and then simply copied into bv at the correct offset on future calls with
|
||||
// the same type t. On https://rsc.googlecode.com/hg/testdata/slow.go, onebitwalktype1
|
||||
// accounts for 40% of the 6g execution time.
|
||||
// NOTE: The bitmap for a specific type t could be cached in t after
|
||||
// the first run and then simply copied into bv at the correct offset
|
||||
// on future calls with the same type t.
|
||||
func onebitwalktype1(t *types.Type, off int64, bv bvec) {
|
||||
if t.Align > 0 && off&int64(t.Align-1) != 0 {
|
||||
Fatalf("onebitwalktype1: invalid initial alignment, %v", t)
|
||||
|
|
|
|||
Loading…
Reference in New Issue