Uh oh!
There was an error while loading. Please reload this page.
[NativeAOT] Move Interlocked null checks to managed, RhpLockCmpXchg64 to C - #100021
Conversation
…ockCmpXchg64/RhpCheckedLockCmpXchg/RhpCheckedXchg to managed code
| CmpXchgRetry | ||
| ;; Check location value is what we expect. | ||
| ALTERNATE_ENTRY RhpCheckedLockCmpXchgAVLocation2 | ||
| ldaxr x10, [x0] |
There was a problem hiding this comment.
The RhpCheckedLockCmpXchgAVLocation2 and RhpCheckedXchgAVLocation2 checks are weird. They seem to be present for the same location that was already null checked and unnecessary.
filipnavara
commented
Mar 20, 2024
Kept as draft, needs to be run through CI. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| bne LOCAL_LABEL(CmpXchg64Retry) | ||
| LOCAL_LABEL(CmpXchg64Exit): | ||
| mov r0, r6 | ||
| dmb |
There was a problem hiding this comment.
The native AOT PAL implementation of InterlockedCompareExchange64 seems to be missing this barrier (PAL_InterlockedOperationBarrier in CoreCLR PAL).
There was a problem hiding this comment.
I added it but I noticed that PAL_InterlockedOperationBarrier is not enabled for arm32. That seems odd.
There was a problem hiding this comment.
I added it but I noticed that
PAL_InterlockedOperationBarrieris not enabled for arm32. That seems odd.
IIRC the native compilers already emit a barrier of their own there so it'd do two barriers (so I guess it's kinda relying on an implementation detail).
There was a problem hiding this comment.
the native compilers already emit a barrier of their own
At very least ARM gcc and ARM clang does, so that explains why it wasn't a problem for ARM32 on CoreCLR.
There was a problem hiding this comment.
ARM64: clang generates barrier at the end (should still be fine); gcc doesn't generate a barrier
| FORCEINLINE void PalInterlockedOperationBarrier() | ||
| { | ||
| #if (defined(HOST_ARM64) && !defined(LSE_INSTRUCTIONS_ENABLED_BY_DEFAULT)) || defined(HOST_ARM) || defined(HOST_LOONGARCH64) || defined(HOST_RISCV64) |
There was a problem hiding this comment.
| #if (defined(HOST_ARM64) && !defined(LSE_INSTRUCTIONS_ENABLED_BY_DEFAULT)) ||defined(HOST_ARM) || defined(HOST_LOONGARCH64) || defined(HOST_RISCV64) | |
| #if (defined(HOST_ARM64) && !defined(LSE_INSTRUCTIONS_ENABLED_BY_DEFAULT)&& !defined(__clang__)) || defined(HOST_LOONGARCH64) || defined(HOST_RISCV64) |
There was a problem hiding this comment.
AFAIK C++ code is not supposed to have compiler specific defines in the runtime.
There was a problem hiding this comment.
Well, other code in the same file already uses __clang__.
There was a problem hiding this comment.
Yes, also _MSC_VER and __llvm__. (I think we can replace all __llvm__ ones to __clang__ for consistency?)
There was a problem hiding this comment.
AFAIK C++ code is not supposed to have compiler specific defines in the runtime
I do not see a problem with this ifdef here.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
jkotas
commented
Mar 22, 2024
@filipnavara Could you please resolve the conflict? |
MichalPetryka
commented
Mar 22, 2024
I did it myself cause I have push perms to filips fork. |
Uh oh!
There was an error while loading. Please reload this page.
MichalPetryka
commented
Mar 22, 2024
Why leave the 32bit one in ASM btw? |
jkotas
commented
Mar 22, 2024
Do you mean the one for Arm? Yes, it would be nice to move it to C as well. Filip have not done it earlier to reduce conflicts with your other PR. |
MichalPetryka
commented
Mar 22, 2024
Only until #97792 is merged.
I don't think we'd even have any conflicts there since they'd both just remove it. |
filipnavara
commented
Mar 22, 2024
Done. |
Ref: #99688 (comment)
Ref: #96916 (similar thing done for CoreCLR)