Comment 1:

Labels changed: added priority-someday.

Comment 2:

Labels changed: added repo-main.

Comment 3:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

Comment 4:

Issue #7515 has been merged into this issue.

Comment 5:

Add Go1.3Maybe per Russ' comment:
"file an issue marked Go1.3Maybe for a test once the new objdump is in" on
https://golang.org/cl/73730043/

Labels changed: added release-go1.3maybe, removed release-none.

Comment 6:

My comment was for a test of the assembler (the conversion to machine encoding); this
bug is about tests of the instructions chosen by the compiler (not their machine
encoding).

Labels changed: added release-none, removed release-go1.3maybe.

Maybe @randall77 will do better than I did.

(Triaging old bugs)

@josharian @mdempsky @brtzsnr, maybe one of you has thoughts on SSA testing? Or maybe the view is that the current testing is satisfactory?

There are still some issues here.

As a recent example, Keith added an optimization to coalesce multiple one byte loads, which got broken, and no one noticed until a new performance bug got filed. I'm not sure how to write a test for that that won't be annoyingly fragile, though.

That's for optimization. The correctness front is looking better, with many SSA-instigated tests. Correctness is easier, because you can just write regular Go, like the 1/0 test that went in today.

Agreed. I think we're in good shape for correctness testing, but we don't have a good solution for testing that instruction-level micro-optimizations are working as intended.

From memory, LLVM has a lot of FileCheck (http://llvm.org/docs/CommandGuide/FileCheck.html) tests, and some of them are used to inspect generated assembly instruction sequences. Maybe we could implement something similar.

The way I tested the compiler for a while was to run randomly generated code on go1.5 go1.6 and dev.ssa and compare the results. I found quite a few bugs in all three versions, and lots of missed optimizations in the new compiler. The sources of the tester are here https://github.com/brtzsnr/gostress. It's limited however to arithmetic operations and branches. No loops, no bounds checking, no calls, no slices, no strings, etc.

For speed I mostly looked at the binary size of pkg/tools/linux_amd64/* which is an indirect measure. Compilebench is also another metric. I also tested changes on my personal projects and saw a speedup of ~2% in the last week. Tracking the performance on a set of benchmarks would be a start (e.g. all benchmarks in stdlib).

Performance regressions are indeed the most problematic. For example I recently retested https://go-review.googlesource.com/#/c/19727/ and concluded it's now a regression. I don't know when that happened and I don't know how to test this.

There is now some infrastructure for such tests, see cmd/compile/internal/gc/asm_test.go. It compiles tests and looks to make sure the right (and not the wrong) instructions are in the generated assembly.

There aren't a whole lot of tests there, but the mechanism is in place. I think that's enough to close this issue.