Reapply "[RISCV] Remove experimental from Ztso. (#96465)"

This was reverted in f985a8826bfa4ca3d23e654185de35e30ea6dc79. Since that,
the default WMO lowering has moved to A67 compatible, the ABI at

Reapply "[RISCV] Remove experimental from Ztso. (#96465)"

This was reverted in f985a8826bfa4ca3d23e654185de35e30ea6dc79. Since that,
the default WMO lowering has moved to A67 compatible, the ABI attribute
emission has landed (off by default), and the LLD change to merge said
attributes have landed. Our ztso lowering is believed to also be A67
compatible, and no known issues remain.

Original commit message:

Ztso 1.0 was ratified in January 2023.
Documentation:
https://github.com/riscv/riscv-isa-manual/blob/main/src/ztso-st-ext.adoc

show more ...

Revert "[RISCV] Remove experimental from Ztso. (#96465)"

This reverts commit 9cd6ef4b8a5c843ef491437c765d4cb2ff2f8fe3. See
discussion on review thread.

[RISCV] Remove experimental from Ztso. (#96465)

Ztso 1.0 was ratified in January 2023.
Documentation:
https://github.com/riscv/riscv-isa-manual/blob/main/src/ztso-st-ext.adoc

[RISCV] Implement a proposed mapping for Ztso

This change implements a proposed lowering from LLVM's memory model to the TSO memory model defined by the Ztso extension. Selecting the proposed mappin

[RISCV] Implement a proposed mapping for Ztso

This change implements a proposed lowering from LLVM's memory model to the TSO memory model defined by the Ztso extension. Selecting the proposed mapping turns out to be an involved conversation that really didn't fit within a review description, so let me refer you to https://github.com/preames/public-notes/blob/master/riscv-tso-mappings.rst. This review implements the WMO compatible variant (the proposed one in that document).

Ztso is currently accepted as an experimental extension in LLVM. Despite the fact the extension was recently ratified, I think we need to leave it as experimental until we have wide agreement on the chosen mapping for ABI purposes.

I need to note that the current in-tree implementation defaults to generating WMO compatible fences. This is entirely compatible with the proposed mapping in this patch, but is unfortunately not compatible with the major alternative. The in tree implementation is explicitly experimental so the impact of this is limited, but it is worth calling out that if settle on the alternative we will have a minor ABI break. My apologies for not calling this out in the original patch; I had not realized at the time that one of our realistic choices for mappings wouldn't be WMO compatible.

This patch only contains the changes for load/store and fence. That is, it does not change the lowering for atomicrmw operations. This is a sound thing to do under the proposed mapping since the existing WMO mappings remain compatible. I do plan to change these; I'm just working incrementally.

Differential Revision: https://reviews.llvm.org/D143076

show more ...

[RISCV] Avoid emitting hardware fences for singlethread fences

singlethread fences only synchronize with code running on the same hardware thread (i.e. signal handlers). Because of this, we need to

[RISCV] Avoid emitting hardware fences for singlethread fences

singlethread fences only synchronize with code running on the same hardware thread (i.e. signal handlers). Because of this, we need to prevent instruction reordering, but do not need to emit hardware fence instructions.

The implementation strategy here matches many other backends. The main motivation of this patch is to introduce the MEMBARRIER node and get some test coverage for it.

Differential Revision: https://reviews.llvm.org/D141311

show more ...

[RISCV] Add -experimental-ztso test coverage

For the moment, this is the same as the default memory model.

[RISCV] Consolidate test lines in fence lowering test

These are identical for RV32 and RV64.

[RISCV] Add test coverage for singlethread fences

[RISCV][NFC] Add CHECK lines for atomic operations on RV64I

As or RV32I, we include these for completeness. Committing now to make it
easier to review the RV64A patch.

llvm-svn: 350962

[RISCV] Codegen support for atomic operations on RV32I

This patch adds lowering for atomic fences and relies on AtomicExpandPass to
lower atomic loads/stores, atomic rmw, and cmpxchg to __atomic_* l

[RISCV] Codegen support for atomic operations on RV32I

This patch adds lowering for atomic fences and relies on AtomicExpandPass to
lower atomic loads/stores, atomic rmw, and cmpxchg to __atomic_* libcalls.

test/CodeGen/RISCV/atomic-* are modelled on the exhaustive
test/CodeGen/PPC/atomics-regression.ll, and will prove more useful once RV32A
codegen support is introduced.

Fence mappings are taken from table A.6 in the current draft of version 2.3 of
the RISC-V Instruction Set Manual, which incorporates the memory model changes
and definitions contributed by the RISC-V Memory Consistency Model task group.

Differential Revision: https://reviews.llvm.org/D47587

llvm-svn: 334590

show more ...