Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64 #101927
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
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.
Is there a register called this on arm32?
There was a problem hiding this comment.
Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr
There was a problem hiding this comment.
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.
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
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
IsUnwindablequestion 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_REGis a better fit for this.