You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: