cmd/compile: improve generated type equality code

[josharian]

geneq generates a series of if statements, each returning false if they fail. Creating instead a long conjunction would result in shorter, faster generated code.

It might also be worth reordering the tests to place all the ones involving a function call last.

It might also be worth trying to prevent some of the spurious checknils that are currently produced. In some cases know that we are dereferencing fields on a struct (not a pointer to a struct).

We also appear to be generating equality routines when we shouldn't be. The following strike me as possibly spurious:

• TEXT type..eq.[0]text/tabwriter.cell(SB) text/tabwriter/tabwriter.go. An array of length zero? Where does it come from? And the equality check should be trivial, not generated.
• TEXT type..eq.[2]string(SB) golang.org/x/tools/cmd/godoc/blog.go. I don't see anything resembling [2]string in blog.go.
• TEXT type..eq.[1]interface {}(SB) golang.org/x/tools/cmd/godoc/blog.go. I don't see where this came from in blog.go. And an equality check for an array of length 1 should just be a check of the underlying type.

Look into these.

Given all the above, it might be worth also taking a closer look at the generated hash routines as well.

I'll poke at these once the c2go conversion is complete.

[josharian]

There's plenty of low-hanging fruit here, but I'm not convinced that it is worth it at this stage in the cycle.

(The last six commits in https://github.com/josharian/go/commits/gc-improve-alg cut 100k off the godoc binary size, and generate better eq code, but that's only ~0.5% of the binary, and I don't see the benchmark numbers move much.)

For Go 1.6, we can pull in those commits and take another pass. I've not looked at the hash routines at all, and I think we're generating way too many alg routines. This won't be as big a deal once the linker can strip them, but it's still pointless.

[randall77]

cmd/internal/gc/subr.go:2610: // TODO: with aeshash we don't need these shift/mul parts

Now that the fallback hash is also decent, we should definitely do this (for 1.6).

[gopherbot]

CL https://golang.org/cl/19768 mentions this issue.

[gopherbot]

CL https://golang.org/cl/19770 mentions this issue.