Up to [cvs.NetBSD.org] / src / common / lib / libc / arch / aarch64 / atomic
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
Pull up following revision(s) (requested by skrll in ticket #1331): common/lib/libc/arch/aarch64/atomic/atomic_add_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_sub_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_sub_64.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_swap_64.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_swap_64.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_inc_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_or_64.S: revision 1.3 common/lib/libc/arch/aarch64/atomic/atomic_and_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_xor_64.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_and_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_nand_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_add_64.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_op_asm.h: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_swap_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_op_asm.h: revision 1.6 common/lib/libc/arch/aarch64/atomic/atomic_cas_64.S: revision 1.4 common/lib/libc/arch/aarch64/atomic/atomic_nand_8.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_sub_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_cas_64.S: revision 1.6 common/lib/libc/arch/aarch64/atomic/atomic_swap_8.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_sub_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_swap_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_nand_64.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_swap_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_xor_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_swap_32.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_or_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_nand_64.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_swap_16.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_or_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_or_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_cas_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_xor_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_cas_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_cas_16.S: revision 1.4 common/lib/libc/arch/aarch64/atomic/atomic_add_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_cas_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_xor_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_dec_64.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_cas_32.S: revision 1.4 common/lib/libc/arch/aarch64/atomic/atomic_add_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_cas_8.S: revision 1.4 common/lib/libc/arch/aarch64/atomic/membar_ops.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_nand_16.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_nand_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_nand_16.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_nand_32.S: revision 1.5 common/lib/libc/arch/aarch64/atomic/atomic_inc_64.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_dec_32.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_and_8.S: revision 1.2 common/lib/libc/arch/aarch64/atomic/atomic_and_64.S: revision 1.2 Part I of ad@'s performance improvements for aarch64 - Remove memory barriers from the atomic ops. I don't understand why thos= e are there. Is it some architectural thing, or for a CPU bug, or just over-caution maybe? They're not needed for correctness. - Have unlikely conditional branches go forwards to help the static branch predictor. Remove memory barriers from the atomic ops macros in the same way as was done for the other atomic ops earlier. Use the correct barriers - all of membar_{sync,producer,consumer} have less scope than before. LGTM from riastradh As we're providing the legacy gcc __sync built-in functions for atomic memory access we might as well get the memory barriers right... From the gcc documentation: In most cases, these built-in functions are considered a full barrier. That is, no memory operand is moved across the operation, either forward or backward. Further, instructions are issued as necessary to prevent the processor from speculating loads across the operation and from queuing stores after the operation. type __sync_lock_test_and_set (type *ptr, type value, ...) This built-in function is not a full barrier, but rather an acquire barrier. This means that references after the operation cannot move to (or be speculated to) before the operation, but previous memory stores may not be globally visible yet, and previous memory loads may not yet be satisfied. void __sync_lock_release (type *ptr, ...) This built-in function is not a full barrier, but rather a release barrier. This means that all previous memory stores are globally visible, and all previous memory loads have been satisfied, but following memory reads are not prevented from being speculated to before the barrier.
As we're providing the legacy gcc __sync built-in functions for atomic memory access we might as well get the memory barriers right... From the gcc documentation: In most cases, these built-in functions are considered a full barrier. That is, no memory operand is moved across the operation, either forward or backward. Further, instructions are issued as necessary to prevent the processor from speculating loads across the operation and from queuing stores after the operation. type __sync_lock_test_and_set (type *ptr, type value, ...) This built-in function is not a full barrier, but rather an acquire barrier. This means that references after the operation cannot move to (or be speculated to) before the operation, but previous memory stores may not be globally visible yet, and previous memory loads may not yet be satisfied. void __sync_lock_release (type *ptr, ...) This built-in function is not a full barrier, but rather a release barrier. This means that all previous memory stores are globally visible, and all previous memory loads have been satisfied, but following memory reads are not prevented from being speculated to before the barrier.
Comment nit
Part I of ad@'s performance improvements for aarch64 - Remove memory barriers from the atomic ops. I don't understand why those are there. Is it some architectural thing, or for a CPU bug, or just over-caution maybe? They're not needed for correctness. - Have unlikely conditional branches go forwards to help the static branch predictor.
Sync with HEAD
Sync with HEAD
Sort STRONG_ALIAS's in the same manner as ATOMIC_OP_ALIAS's. No functional changes.
Export _atomic_cas_64 as atomic_cas_64_ni. Note that _atomic_cas_64 is already exported as atomic_cas_{ulong,prt}_ni. Fix build error of test/lib/atomic/t_atomic_cas, which is successfully passed on RPI3B+ now.
Rebase to HEAD as of a few days ago.
file atomic_cas_64.S was added on branch tls-maxphys on 2014-08-19 23:45:12 +0000
Preliminary files for AARCH64 (64-bit ARM) support. Enough for a distribution build.