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>

diff --git a/src/cmd/compile/internal/gc/plive.go b/src/cmd/compile/internal/gc/plive.go
index 444e5e684ecdf7193bb8893b2d2a6ac800239427..9d2dcf658f9a7d573f19ba56e8544d3c70fc573c 100644 (file)
--- a/src/cmd/compile/internal/gc/plive.go
+++ b/src/cmd/compile/internal/gc/plive.go
@@ -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)