[RISC-V] Use fine-grained fence variants for memory barriers

[JamieMagee]

instGen_MemoryBarrier on RISC-V ignored the barrierKind parameter and always emitted fence rw,rw. The RISC-V fence instruction has per-bit control over predecessor and successor ordering (read, write, or both), so there's no reason to always use the heaviest option.

This maps BarrierKind to the matching fence variant:

BarrierKind	Before	After
BARRIER_FULL	fence rw,rw	fence rw,rw (unchanged)
BARRIER_LOAD_ONLY	fence rw,rw	fence r,rw (acquire)
BARRIER_STORE_ONLY	fence rw,rw	fence rw,w (release)

ARM64 does the same thing with DMB ISHLD for load-only and DMB ISH for full. The load/store variants use acquire/release semantics rather than just load-load or store-store ordering, since .NET's volatile semantics require it.

The two call sites that benefit today are GT_MEMORYBARRIER with GTF_MEMORYBARRIER_LOAD/GTF_MEMORYBARRIER_STORE flags, and the post-volatile-CpBlk load barrier.

Validated the encoding on QEMU (fence rw,rw = 0x0330000f, fence r,rw = 0x0230000f, fence rw,w = 0x0310000f).

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR improves RISC-V64 JIT codegen for memory barriers by honoring BarrierKind and emitting a more specific fence variant instead of always using the heaviest fence rw,rw.

Changes:

• Extends RISC-V64 insBarrier immediates to represent multiple fence predecessor/successor masks.
• Updates CodeGen::instGen_MemoryBarrier (RISC-V64) to select the fence immediate based on BarrierKind.
• Cleans up outdated comments that claimed only full barriers were supported.

Show a summary per file

File	Description
src/coreclr/jit/instr.h	Adds additional RISC-V64 insBarrier values intended to represent different fence masks.
src/coreclr/jit/codegenriscv64.cpp	Uses BarrierKind to pick an insBarrier immediate when emitting INS_fence.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 2

[Copilot]

Pull request overview

This PR refines RISC-V64 JIT memory barrier emission so instGen_MemoryBarrier(BarrierKind) uses the appropriate fence predecessor/successor mask instead of always emitting the heaviest fence rw,rw, aligning barrier strength with .NET volatile semantics.

Changes:

• Add RISC-V-specific insBarrier encodings for full, load-only (acquire), and store-only (release) fences.
• Update CodeGen::instGen_MemoryBarrier on RISC-V64 to select the correct fence variant based on BarrierKind.
• Remove an outdated TODO that stated only full barriers were supported on RISC-V64.

Show a summary per file

File	Description
src/coreclr/jit/instr.h	Defines RISC-V64 fence immediate values for full/load-only/store-only barrier variants.
src/coreclr/jit/codegenriscv64.cpp	Maps BarrierKind to the corresponding RISC-V64 fence variant during codegen.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 1

[Copilot]

The comment says this emits an INS_BARRIER_RMB after a volatile CpObj, but on RISC-V there is no INS_BARRIER_RMB variant and the code is emitting BARRIER_FULL here. This is misleading (and now that load/store-only barriers exist it’s easy to misread). Please update the comment to match what is actually emitted (e.g., “full memory barrier after ...” or “load barrier after ...” if you decide to use BARRIER_LOAD_ONLY here).

Suggested change

	// issue a INS_BARRIER_RMB after a volatile CpObj operation
	// issue a full memory barrier after a volatile CpObj operation

[tomeksowi]

Thanks