[RyuJIT][LSRA] Evaluate jit-time impact of recording preferences at each kill

[CarolEidt]

In LinearScan::buildKillPositionsForNode the preferences for all interfering lclVar intervals are updated to avoid those registers. There may be a more efficient way to achieve this.
(This issue was migrated from the desktop bug tracking system.)
category:throughput
theme:register-allocator
skill-level:expert
cost:large

[CarolEidt]

An alternative would be to defer updating the preference sets until after the RefPositions are built:

• Identify all the different kill sets (of course, this would be target-specific), and maintain a set of lclVars that is killed by each type of kill.
• In buildKillPositionsForNode(), instead of iterating over the live vars right at that point, simply add the live vars to the appropriate kill set.
• Iterate over the different kill sets after all the RefPositions have been built, adding preferencing.
  • One could also identify those kill sets that are subsets of one another (also target-specific) and only use the difference for the smaller set, e.g. RBM_INT_CALLEE_TRASH < RBM_CALLEE_TRASH.
• I think that this would mostly affect the code in buildKillPositionsForNode(), and the code to do the preferencing could be moved to a method that’s called after the RefPositions have been built (near “if (compiler->lvaKeepAliveAndReportThis()” in LinearScan::buildIntervals())
• I think it’s possible that this could slightly negatively impact small methods, but I think the overall impact would be very good.

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.