yonghong-song added inline comments.
================
Comment at: llvm/test/CodeGen/BPF/atomics_2.ll:14
+; int test_xchg_64(long *p, long v) {
+; return __sync_lock_test_and_set(p, v);
+; }
----------------
ast wrote:
> test_and_set is not the same as xchg.
> xchg doesn't do comparison.
I am looking at here:
https://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
which mentions:
type __sync_lock_test_and_set (type *ptr, type value, ...)
This builtin, as described by Intel, is not a traditional test-and-set
operation, but rather an atomic exchange operation. It writes value into *ptr,
and returns the previous contents of *ptr.
Many targets have only minimal support for such locks, and do not support a
full exchange operation. In this case, a target may support reduced
functionality here by which the only valid value to store is the immediate
constant 1. The exact value actually stored in *ptr is implementation defined.
This builtin is not a full barrier, but rather an acquire barrier. This
means that references after the builtin cannot move to (or be speculated to)
before the builtin, but previous memory stores may not be globally visible yet,
and previous memory loads may not yet be satisfied.
So it does not do compare.
Or alternatively for llvm atomic builtin,
https://llvm.org/docs/Atomics.html
We have:
iN __atomic_load_N(iN *ptr, iN val, int ordering)
void __atomic_store_N(iN *ptr, iN val, int ordering)
iN __atomic_exchange_N(iN *ptr, iN val, int ordering)
bool __atomic_compare_exchange_N(iN *ptr, iN *expected, iN desired, int
success_order, int failure_order)
But as I mentioned in bpf office hour meeting, a "ordering" is required and I
do not know how to deal with it.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72184/new/
https://reviews.llvm.org/D72184
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
