cmd/compile: unnecessary hash/eq functions for slice literals

[neild]

What version of Go are you using (go version)?

$ go version
go version go1.12rc1 linux/amd64

Consider this package:

package bloat
var x []interface{}

$ go build -o bloat.a .
$ ls -l bloat.a
-rw-r--r-- 1 dneil primarygroup 778 Feb 27 15:23 bloat.a

Now consider the case where we initialize the var x:

package bloat
var x = []interface{}{0, 1, 2}

$ go build -o bloat.a .
$ ls -l bloat.a
-rw-r--r-- 1 dneil primarygroup 4030 Feb 27 15:28 bloat.a

The object file for the latter package contains eq and hash functions for [3]interface{}, which appear to account for much of the size increase:

$ go tool pack x bloat.a
$ go tool objdump -S bloat.a | grep ^TEXT
TEXT type..hash.[3]interface {}(SB) gofile..<autogenerated>
TEXT type..eq.[3]interface {}(SB) gofile..<autogenerated>

There is no need for these functions, however; the only use of [3]interface{} is to initialize a []interface{}, and there is no way to recover the array type from that slice.

[randall77]

I have a CL related to this: https://go-review.googlesource.com/c/go/+/151497/
It's buggy somehow - I haven't dug back in to what the issue was.

Presumably the whole [3]interface{} type, including algorithms, is dead-code eliminated when linking.

[martisch]

I was also noticing this and was looking into this for go1.13 and had made an issue related to this as the hash and eq is on the backing array #28639.

Also for performance which also improves the size for the non deadcode eliminated algs:
https://go-review.googlesource.com/c/go/+/148177

[dsnet]

I just filed #30528 as a more generalized version of this problem. I imagine that its harder to resolve than this one here since it requires a wider-scope static analysis to prove certain facts.