wangpc-pp wrote:
> Can we split the CodeGen part out of this patch?
MC part is https://github.com/llvm/llvm-project/pull/78970.
This PR will be the CodeGen part and I will update this PR later.
https://github.com/llvm/llvm-project/pull/77424
___
cfe-c
topperc wrote:
> > I guess Zaamo + Zacas is technically a way one could implement atomics
> > without LR/SC?
>
> The Zacas extension depends upon the A extension.
I filed an issue asking about that
https://github.com/riscv/riscv-zaamo-zalrsc/issues/5
https://github.com/llvm/llvm-project/pull
dtcxzyw wrote:
> I guess Zaamo + Zacas is technically a way one could implement atomics
> without LR/SC?
The Zacas extension depends upon the A extension.
https://github.com/llvm/llvm-project/pull/77424
___
cfe-commits mailing list
cfe-commits@lists
jrtc27 wrote:
I guess Zaamo + Zacas is technically a way one could implement atomics without
LR/SC?
https://github.com/llvm/llvm-project/pull/77424
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
asb wrote:
Thanks James, that matches what I'd understood. Just one comment on this though:
> If Zaamo is present, but neither Zalrsc nor Zacas are present, I think
> there's no way to implement a cmpxchg operation. This means lock-free atomics
> cannot be supported, so it should `setMaxAtomic
jyknight wrote:
There's two sets of atomic functions:
`__atomic_*` are provided by libatomic, and might use locking, or not.
`__sync_*` should always be lock-free. These are only used on certain
architectures where it's guaranteed that the operation _can_ be implemented
lock-free, but it's desi
asb wrote:
CC @jyknight who can hopefully confirm if my interpretation is correct. Based
on your comment on #77814, perhaps the expectation is that libatomic would have
a lock-free implementation for any __sync calls used up to the max atomic width
(e.g. lr/sc based if there's no AMO instructi
@@ -0,0 +1,11 @@
+# RUN: not llvm-mc -triple riscv32 -mattr=+experimental-zaamo < %s 2>&1 |
FileCheck %s
dtcxzyw wrote:
Can we split `rv32a-invalid.s` into two files? I think it is better than
duplicating tests for new extensions.
https://github.com/llvm/llvm
llvmbot wrote:
@llvm/pr-subscribers-clang
@llvm/pr-subscribers-mc
Author: Wang Pengcheng (wangpc-pp)
Changes
`A` extension has been split into two parts: Zaamo (Atomic Memory
Operations) and Zalrsc (Load-Reserved/Store-Conditional). See also
https://github.com/riscv/riscv-zaamo-zalrsc.
Th