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

JIT LSRA Throughput: Short-circuit register selection #6705

Closed
CarolEidt opened this issue Sep 21, 2016 · 4 comments
Closed

JIT LSRA Throughput: Short-circuit register selection #6705

CarolEidt opened this issue Sep 21, 2016 · 4 comments
Assignees
Labels
area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI enhancement Product code improvement that does NOT require public API changes/additions JitThroughput CLR JIT issues regarding speed of JIT itself needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration tenet-performance Performance related issue
Milestone

Comments

@CarolEidt
Copy link
Contributor

The loop over all the candidate registers in LinearScan::tryAllocateFreeReg() and in LinearScan::allocateBusyReg() could be short-circuited when a register is found that has the best possible score. Additionally, in the case of MinOpts, it could potentially short-circuit as soon as a suitable candidate is found, though one would want to weight the throughput benefit against the code quality impact.

category:throughput
theme:register-allocator
skill-level:expert
cost:medium

@RussKeldorph
Copy link
Contributor

/cc @sivarv

@pgavlin
Copy link
Contributor

pgavlin commented Jun 20, 2017

The loop over all the candidate registers in LinearScan::tryAllocateFreeReg() and in LinearScan::allocateBusyReg() could be short-circuited when a register is found that has the best possible score

Outside of minopts, is it possible to know the best possible score for a particular attempt a priori?

@CarolEidt
Copy link
Contributor Author

Outside of minopts, is it possible to know the best possible score for a particular attempt a priori?

So, a bit more description would have been warranted here, and mea culpa for that (this issue has been around for a very long time before migrating from the old work items, and I just copied most of the text from there). There are a couple of ways a register is evaluated as a candidate. The first is the score. And it is possible to know the best possible score based on the characteristics of the RefPosition itself, e.g. whether it has a relatedInterval. However, the second consideration is comparing the location of the next use of the physical register (currently, since we don't do any pre-allocation, that's always a fixed reg reference). Determining the best value for that a priori doesn't seem really practical. However, the way I currently think about this "short-circuiting" is that for both tryAllocateFreeReg and allocateBusyReg, we should ensure that 1) the cheaper and higher value criteria are evaluated first, and as soon as it fails a criteria that would cause it be scored lower than an existing candidate, the loop should short-circuit. I think that, to accomplish this cleanly, those methods could use some cleaning up.

It may be that we could maintain a list of available registers, sorted by nearest next reference. Then it would indeed be possible to short-circuit. That said, one would want to evaluated the throughput impact of the various options.

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@CarolEidt CarolEidt modified the milestones: Future, 6.0.0 Oct 27, 2020
@JulieLeeMSFT JulieLeeMSFT added the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Mar 23, 2021
@kunalspathak
Copy link
Member

We did fair amount of refactoring in #45135 that would short circuit the other heuristics once we found a single register candidate out of set of registers.

@ghost ghost locked as resolved and limited conversation to collaborators May 9, 2021
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 enhancement Product code improvement that does NOT require public API changes/additions JitThroughput CLR JIT issues regarding speed of JIT itself needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration tenet-performance Performance related issue
Projects
None yet
Development

No branches or pull requests

6 participants