[NativeAOT] Move Interlocked null checks to managed, RhpLockCmpXchg64 to C#100021
[NativeAOT] Move Interlocked null checks to managed, RhpLockCmpXchg64 to C#100021jkotas merged 10 commits intodotnet:mainfrom
Conversation
…ockCmpXchg64/RhpCheckedLockCmpXchg/RhpCheckedXchg to managed code
ghost
added
the
dotnet-policy-service
bot
added
the
community-contribution
| 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.
|
Kept as draft, needs to be run through CI. |
src/coreclr/nativeaot/System.Private.CoreLib/src/System/Threading/Interlocked.cs
Show resolved
Hide resolved
| 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.
|
@filipnavara Could you please resolve the conflict? |
|
I did it myself cause I have push perms to filips fork. |
Why leave the 32bit one in ASM btw? |
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. |
Only until #97792 is merged.
I don't think we'd even have any conflicts there since they'd both just remove it. |
Done. |
4 participants
Ref: #99688 (comment)
Ref: #96916 (similar thing done for CoreCLR)