[arm64] Add RCPC ISA (8.3+) and use ldap for volatile reads

[EgorBo]

This PR adds a new ISA RCPC (Release Consistent Processor Consistent support) for arm64-v8.3+ (optionally available on arm64-v8.2) in order to rely on ldapr/b/h for volatile reads with acquire/release semantics, see #67374

Apple M1 seems support it but most likely it's just an alias for ldar there so no boost.

Closes #67374

static volatile int a;

static void Test() => a++;

codegen diff

; Assembly listing for method Test()
G_M16289_IG01: 
        A9BF7BFD          stp     fp, lr, [sp,#-16]!
        910003FD          mov     fp, sp
G_M16289_IG02:
        D287BA80          movz    x0, #0x3dd4
        F2B00C00          movk    x0, #0x8060 LSL #16
        F2C00040          movk    x0, #2 LSL #32
-       88DFFC01          ldar    w1, [x0]
+       B8BFC001          ldapr   w1, [x0]
        11000421          add     w1, w1, #1
        889FFC01          stlr    w1, [x0]
G_M16289_IG03:
        A8C17BFD          ldp     fp, lr, [sp],#16
        D65F03C0          ret     lr
; Total bytes of code 40
; ============================================================

[ghost]

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

Issue Details

---

This PR adds a new ISA RCPC (Release Consistent Processor Consistent support) for arm64-v8.3+ (optionally available on arm64-v8.2) in order to rely on ldapr/b/h for volatile reads with acquire/release semantics, see #67374

Closes #67374

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@VSadov do you have a benchmark/scenario in mind to see improvements from this change?

[VSadov]

@EgorBo This can have effect on scenarios that mix volatile writes and reads. Like writing/reading to ConcurrentQueue in a loop.

The new instruction is not necessarily cheaper by itself - scenarios just doing lots of volatile reads may not be affected. There need to be some volatile writes (or reference writes to heap locations) in the mix as LDAR needs to consider preceding STLR while LDAPR does not.

Also note that in order to see gains, the hardware should take advantage of relaxed semantics. Some early implementations of LDAPR could be just aliases of LDAR.

[EgorBo]

I wasn't able to reproduce improvements on M1 so probably it is indeed is just a renamed ldar there but I guess it's still makes sense to have - I've attached a codegen diff example in the description.

@dotnet/jit-contrib PTAL, no diffs but in fact all volatile loads were changed from ldar[b/h] to ldapr[b/h]

[EgorBo]

NOTE: Unfortunately, this PR doesn't detect RCPC feature set on Windows as there is no official API for that yet.

[kunalspathak]

NOTE: Unfortunately, this PR doesn't detect RCPC feature set on Windows as there is no official API for that yet.

This was originally added for Mac, right? Were you trying it on Ampere for Windows?

[EgorBo]

NOTE: Unfortunately, this PR doesn't detect RCPC feature set on Windows as there is no official API for that yet.

This was originally added for Mac, right? Were you trying it on Ampere for Windows?

Yep, and Linux. Unfortunately it happened before we added Ampere+Linux to our perf infra. For windows we wait till the official API is updated IsProcessorFeaturePresent