cmd/compile: Renumbering Value IDs before register allocation can save time/space

[dr2chase]

Some large inputs (see #15537) create a large number of ssa values early in the compilation, but most of those disappear early (because of excess LocalRef/Copy/Phi creation that is optimized out). Func.NumValues() however continues to return the high-water-mark for value ID, which leads to overallocation of various intermediate data structures. This is especially costly in register allocation.

Renumbering the range of Value Ids to compress the range saves time and space.

The benefits of renumbering are reduced by other methods for reducing unnecessary Value creation; eliminating Call blocks is one way (see #15631 for this), sparse methods for finding/creating phi functions is another (see https://go-review.googlesource.com/#/c/22342/ ). Renumbering will interfere with tracking values in the ssa.html debugging output; however, for the inputs where renumbering produces a noticeable improvement the ssa.html files are so large as to be unwieldy (gigabytes).
#15631 contains an early discussion of the motivation for this bug/fix.

[gopherbot]

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

[rsc]

The comment on the abandoning of the CL makes it sound like we decided this was not something we wanted to do after all.

[dr2chase]

The desirability depends almost entirely on whether or not any particular phase creates a zillion value nodes that then go dead, because the maximum value index is what determines the memory footprint of some operations. Right now that seems not to be happening, so we're okay without it.

AND, if you do this, and you need to debug the SSA code, tracing values between phases gets much harder.