[RyuJIT][CQ] LSRA: Investigate separating cross-block lclVars from intra-block lclVars

[CarolEidt]

Much of LSRA work involves dealing with sets of vars that are live at block boundaries.
We could improve efficiency by ensuring that those sets are dense, and using a smaller set.
We would only need a larger set for the liveness set that's used during traversals.
This could be beneficial if 1) there are a large number of vars that are only live within a single block, and 2) the cost of the extra sorting and updating of the "current" copy of live vars doesn't adversely impact throughput.
Also, it may be possible to reuse tracked numbers for different basic blocks, to keep the sets small. The Intervals could still be different for the different lclNums with the same BB-local tracked var number.
category:throughput
theme:register-allocator
skill-level:expert
cost:large

[CarolEidt]

In addition to ensuring that the sets of live lclVars at block boundaries are dense, we should ensure that non-register-candidates that are tracked (e.g. tracked structs that are not promoted) are not mixed in with the register candidates. Further, if the liveness info for non-register-candidates doesn't impact GC reporting, there is no reason to make those tracked after the optimization phases have completed.

[mikedn]

Sort of related question: would it help LSRA to eliminate all SDSU intra-block lclvars?

[CarolEidt]

Sort of related question: would it help LSRA to eliminate all SDSU intra-block lclvars?

Yes, I think it would help (at a minimum it would eliminate the extra RefPosition associated with assigning the value. The question would be whether eliminating them would be more cost than the potential benefit.

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.