-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64 #101927
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
@@ -3672,11 +3672,11 @@ void CodeGen::genCallInstruction(GenTreeCall* call) | |||
{ | |||
#ifdef TARGET_ARM | |||
// For arm32 we've allocated an internal register to load the target into. | |||
// Loading into lr takes 4 bytes (instead of potentially 2 with another register). | |||
// Loading into IP takes 4 bytes (instead of potentially 2 with another register). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a register called this on arm32?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I wasn't aware of that alias. R12 would be problematic to use anyway because we use it as an argument register in a bunch of a cases.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I was not aware that we cannot use LR as a GPR. Is that just a coreclr constraint or a more general property for arm64?
For arm32, we definitely use LR as a scratch register in more cases (REG_SCRATCH
is defined as REG_LR
). Is that problematic?
That is not illegal. It is just was not done before and at the time when the epilog detection heuristic was introduced, we assumed it will not be needed in the future. We had a small discussion about that.
Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns. I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info. |
/azp run runtime-nativeaot-outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
…ude LR from availableIntRegs
All tests are green, including NativeAOT outer loop. I will add a commit with a comment about current dependency on LR not being a GPR. |
Thanks!!! |
…101927) * Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64 * Added a comment about NativeAOT dependency at the place wehre we exclude LR from availableIntRegs
…101927) * Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64 * Added a comment about NativeAOT dependency at the place wehre we exclude LR from availableIntRegs
Fixes: #101896
With #101647 we started using LR as a general purpose register when doing indirect calls and that broke our logic on NativeAOT that detects whether a thread is in an epilog on linux-arm64
Using LR as a GPR is not illegal, just something that we did not do before, so once we see LR (or FP) loaded with some value, the epilog detection logic assumes that we are in an epilog.
Long-term (and assuming that some platforms will never learn how to unwind in epilogs), I think we should encode the epilog ranges. In GC info, I suppose. It will not be trivial as there could be more than one epilog in a method, so encoding them all and then searching through them to answer
IsUnwindable
question could be a bit tricky. However, it will be a more portable approach.For now we can have a simpler fix - we do not have to use LR for indirect call targets, so let's not use it.
It seems like
REG_INDIRECT_CALL_TARGET_REG
is a better fit for this.