JitArm64: Hardcode fewer registers in EmitBackpatchRoutine #13256
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Preparation for the next commit, which will make EmitBackpatchRoutine allocate registers on its own. Because the register allocation will change during the call to EmitBackpatchRoutine, the set of GPRs/FPRs to push can't be computed prior to the call, so let's compute them during the call instead.
This cuts down on how much callers have to think about what registers EmitBackpatchRoutine is using. Also, by allocating registers dynamically instead of using a fixed set of registers, we improve codegen in cases where the fixed registers are taken but other registers are free. (These improvements don't apply to the emitting_routine == true case, where everything still works like before by necessity.)
When EmitBackpatchRoutine emits slow access code for a load, RS must not be in scratch_gprs/scratch_fprs if we have memchecks (otherwise the memcheck exit won't be able to save RS properly), and RS must be in scratch_gprs/scratch_fprs if we don't have memchecks (otherwise RS will be restored to the value it had before the load, overwriting the result of the load). Let's save callers from having to think about this by embedding the relevant logic inside EmitBackpatchRoutine.
There's no reason why this register should be 64-bit. It always contains a 32-bit value, since guest addresses are 32-bit.
This is possible now that EmitBackpatchRoutine lets the caller choose addr register. Note: The removed MOV is actually traded for one added MOV in farcode.
I'm adding a new function to the register cache called GetRegWithPreference. If the passed-in register is unlocked, it gets locked. Otherwise, GetReg is called. The function also has a GetScopedRegWithPreference variant. Then, I'm making JitArm64 call this function when allocating an address register for use with EmitBackpatchRoutine. This way, when register pressure is low we can use the optimal register, and when register pressure is high (but not completely full) we can sacrifice a bit of farcode size for not having to evict a register from the register cache.
JosJuice
force-pushed
the
jitarm64-backpatch-registers
branch
from
337c0fc to
7417efe
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This cuts down on how much callers have to think about what registers EmitBackpatchRoutine is using. Also, by allocating registers dynamically instead of using a fixed set of registers, we improve codegen in cases where the fixed registers are taken but other registers are free.
(These improvements don't apply to the
emitting_routine == truecase, where everything still works like before by necessity.)