Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64 by VSadov · Pull Request #101927 · dotnet/runtime

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

VSadov · 2024-05-06T17:15:21Z

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.

dotnet-policy-service · 2024-05-06T17:15:47Z

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

jakobbotsch · 2024-05-06T18:06:11Z

 #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).


Is there a register called this on arm32?

Yes (IP/r12 I think), but i think it cannot be loaded in 2byte instr

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.

jakobbotsch

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?

VSadov · 2024-05-06T18:18:14Z

Thanks! I was not aware that we cannot use LR as a GPR

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.

For arm32, we definitely use LR as a scratch register in more cases.

Not sure how that is handled. Either Arm32 can unwind in epilog (unlikely), or has more complex heuristic that looks for actual epilog patterns.
On arm64 we could get away with just looking for LR/FP loads vs. something that is never in an epilog (calls, branches...).

I've logged a bug to replace this practice with something more robust - like storing the epilog ranges in GC info.
#101932

VSadov · 2024-05-06T18:27:43Z

/azp run runtime-nativeaot-outerloop

azure-pipelines · 2024-05-06T18:27:58Z

Azure Pipelines successfully started running 1 pipeline(s).

…ude LR from availableIntRegs

VSadov · 2024-05-07T03:06:20Z

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.

VSadov · 2024-05-07T06:20:13Z

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

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Use REG_INDIRECT_CALL_TARGET_REG for indirect calls on arm64
3d7bed5

ghost added the area-CodeGen-coreclr CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI label May 6, 2024

dotnet-policy-serviceBot assigned VSadov May 6, 2024

VSadov requested a review from jakobbotsch May 6, 2024 17:30

jakobbotsch reviewed May 6, 2024
View reviewed changes

jakobbotsch approved these changes May 6, 2024
View reviewed changes

Added a comment about NativeAOT dependency at the place wehre we excl…
0b3c0d1
…ude LR from availableIntRegs

VSadov merged commit e1c6717 into dotnet:mainMay 7, 2024

VSadov deleted the fix101896 branch May 7, 2024 06:20

github-actionsBot locked and limited conversation to collaborators Jun 6, 2024

Uh oh!

Conversation

VSadov commented May 6, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented May 6, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakobbotsch left a comment

Choose a reason for hiding this comment

Uh oh!

VSadov commented May 6, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

VSadov commented May 6, 2024

Uh oh!

azure-pipelinesBot commented May 6, 2024

Uh oh!

VSadov commented May 7, 2024

Uh oh!

VSadov commented May 7, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

VSadov commented May 6, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented May 6, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jakobbotsch left a comment

Choose a reason for hiding this comment

Uh oh!

VSadov commented May 6, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

VSadov commented May 6, 2024

Uh oh!

azure-pipelinesBot commented May 6, 2024

Uh oh!

VSadov commented May 7, 2024

Uh oh!

VSadov commented May 7, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

VSadov commented May 6, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dotnet-policy-serviceBot commented May 6, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

VSadov commented May 6, 2024•
edited
Loading

VSadov commented May 6, 2024•
edited
Loading

VSadov commented May 6, 2024•
edited
Loading

VSadov commented May 6, 2024•
edited
Loading

VSadov commented May 6, 2024•
edited
Loading

VSadov commented May 6, 2024•
edited
Loading

VSadov commented May 6, 2024•
edited
Loading