In CL 35554 for #18704, @josharian added some very nice allocation optimizations, as part of his efforts to claw back some of the allocation penalty of #8405, but a result was a modest increase in binary size.

In CL 35554, @josharian mentioned that the ~0.5% binary size increase could likely be recovered in the future, and there was some discussion of adding a tracking issue for that.

I did a quick look for that follow-up tracking issue a couple years ago, and again searched just now, but both times haven't found it.

Posting this new issue now in case it is helpful to either:

1. serve as the tracking issue for that possible future work, or
2. if that is already tracked (or even completed!), help a future gopher more easily follow the issue trail through cross linking ;-)

Here is a snippet from CL 35554:

This CL adds ~0.5% to binary size, despite
decreasing the size of many functions,
because it also adds many static symbols.

This binary size regression could be recovered in
future (but currently unplanned) work.

There is a lot of content-duplication in these
symbols; this statement generates six new symbols,
three containing an int 1 and three containing
a pointer to the string "a":

fmt.Println(1, 1, 1, "a", "a", "a")

These symbols could be made content-addressable.

Furthermore, these symbols are small, so the
alignment and naming overhead is large.
As with the go.strings section, these symbols
could be hidden and have their alignment reduced.

Another reason for posting now is that there is some recent renewed energy around binary size (#6853).

Sorry if I missed something obvious. @josharian or anyone else, feel free to close if this is already addressed or tracked elsewhere.