cmd/compile: CL 36170 caused some .a archives to grow

[mdempsky]

CL 36170 changed the exporter code's logic for identifying which objects need to be reexported. Most packages shrunk a little from this (0.08% geometric mean reduction), but a couple packages grew. Most notably, compress/zlib.a grew by 200 bytes.

The growth shouldn't be problematic, but it's somewhat unexpected. Seems worth double checking the cause.

I'm guessing it just caused objects to be exported in a different order, and some commonly referenced object ended up with a longer varint-encoded ID.

[bradfitz]

Ping @mdempsky.

[mdempsky]

zlib.a grew in size because after CL 36170, cmd/compile is no longer inlining (*adler32.digest).Reset into (*zlib.reader).Reset:

$ go build -a -toolexec=toolstash -gcflags=-m compress/zlib 2>&1 | grep 'compress/zlib/reader.go:175: inlining'
compress/zlib/reader.go:175: inlining call to adler32.New
compress/zlib/reader.go:175: inlining call to adler32.(*adler32.digest).Reset
$ go build -a -gcflags=-m compress/zlib 2>&1 | grep 'compress/zlib/reader.go:175: inlining'
compress/zlib/reader.go:175: inlining call to adler32.New

That's in turn because CL 36170 caused hash/adler32 to not export any of adler32.digest's method bodies. The cause is we now don't discover that we need to export adler32.digest until we're already writing out the adler32.New function body.

It looks like the problem is "for i, f := range p.funcList" in bexport.go. It needs to be changed to a non-range-based loop because funcList can now grow.

[gopherbot]

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