While looking at reordering the sccp pass I was trying to see what kind of hits it gets and what happens with them.
After looking 5 "random" findings from go build -a -gcflags=-d=ssa/sccp/debug=1 std I find that all of them are deadcode.
So I've added this diff:
diff --git a/src/cmd/compile/internal/ssa/compile.go b/src/cmd/compile/internal/ssa/compile.go
index c749ea9013..ad581b7114 100644
--- a/src/cmd/compile/internal/ssa/compile.go
+++ b/src/cmd/compile/internal/ssa/compile.go
@@ -476,6 +476,7 @@ var passes = [...]pass{
{name: "branchelim", fn: branchelim},
{name: "late opt", fn: opt, required: true}, // TODO: split required rules and optimizing rules
{name: "dead auto elim", fn: elimDeadAutosGeneric},
+ {name: "generic deadcode for sccp", fn: deadcode},
{name: "sccp", fn: sccp},
{name: "generic deadcode", fn: deadcode, required: true}, // remove dead stores, which otherwise mess up store chain
{name: "late fuse", fn: fuseLate},
By grepping and sorting through sccp's debug info, while building std here is the number of hits:
1364 before.processed.sorted
863 after.processed.sorted
before means without the diff above (without rerunning deadcode right before sccp)
after means with the diff above (rerunning deadcode right before sccp)
Very rough timings suggest this is a net compilation speed win.
I'll post correctly measured benchmarks later.
While looking at reordering the
sccppass I was trying to see what kind of hits it gets and what happens with them.After looking 5 "random" findings from
go build -a -gcflags=-d=ssa/sccp/debug=1 stdI find that all of them are deadcode.So I've added this diff:
By grepping and sorting through sccp's debug info, while building
stdhere is the number of hits:beforemeans without the diff above (without rerunning deadcode right beforesccp)aftermeans with the diff above (rerunning deadcode right beforesccp)Very rough timings suggest this is a net compilation speed win.
I'll post correctly measured benchmarks later.