Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[LSRA] Further tuning of preferencing is needed #11959

Closed
CarolEidt opened this issue Feb 2, 2019 · 2 comments
Closed

[LSRA] Further tuning of preferencing is needed #11959

CarolEidt opened this issue Feb 2, 2019 · 2 comments
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI tenet-performance Performance related issue

Comments

@CarolEidt
Copy link
Contributor

LSRA preferencing was improved with dotnet/coreclr#19429, but additional tuning is needed.
On x86, the Span.IndexerBench benchmark, the changes caused additional spill in some key methods due to different allocation choices. Specifically:

  • Span.IndexerBench:TestSameIndex1(struct,int,int):ubyte - V02 gets spilled
  • Span.IndexerBench:TestCoveredIndex2(struct,int,int):ubyte - V02 gets spilled
  • Span.IndexerBench:TestIndexer6(struct):ubyte - V02 gets spilled
  • Span.IndexerBench:TestCoveredIndex3(struct,int,int):ubyte - V04 gets spilled

Another area to investigate (probably independent from the above), is that it seems logical that RefPosition::getRangeEndRef() should only return 'nextRefPosition' if it is a lastUse and otherwise return lastRefPosition, but that tends to excessively lengthen the range for heuristic purposes. Another option might be to iterate to the next lastUse, but that might have excess throughput impact.

category:cq
theme:register-allocator
skill-level:expert
cost:large

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
Copy link
Contributor

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.

@dotnet-policy-service dotnet-policy-service bot added backlog-cleanup-candidate An inactive issue that has been marked for automated closure. no-recent-activity labels Apr 2, 2024
Copy link
Contributor

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.

@dotnet-policy-service dotnet-policy-service bot removed this from the Future milestone Apr 17, 2024
@github-actions github-actions bot locked and limited conversation to collaborators May 17, 2024
@dotnet-policy-service dotnet-policy-service bot removed no-recent-activity backlog-cleanup-candidate An inactive issue that has been marked for automated closure. labels May 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI tenet-performance Performance related issue
Projects
None yet
Development

No branches or pull requests

2 participants