This patch is a revised version of the fix for PR other/113336. Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently has a large number of FAILs in libatomic (regressions since last time I attempted this). The failure mode is related to IFUNC handling with the file tas_8_2_.o containing an unresolved reference to the function libat_test_and_set_1_i2. The following one line change, to build tas_1_2_.o when building tas_8_2_.o, resolves the problem for me and restores the libatomic testsuite to 44 expected passes and 5 unsupported tests [from 22 unexpected failures and 22 unresolved testcases]. ` 2024-02-14 Roger Sayle <roger@nextmovesoftware.com> Victor Do Nascimento <victor.donascimento@arm.com> libatomic/ChangeLog PR other/113336 * Makefile.am: Build tas_1_2_.o on ARCH_ARM_LINUX * Makefile.in: Regenerate.
The exception defines in <fenv.h> do not match the exception bits in the FPU status register on hppa-linux and hppa64-hpux11.11. On linux, they match the trap enable bits. On 64-bit hpux, they match the exception bits for IA64. The IA64 bits are in a different order and location than HPPA. HP uses table look ups to reorder the bits in code to test and raise exceptions. All the architectures that I looked at just pass the FPU status register to __atomic_feraiseexcept(). The simplest approach for hppa is to define FE_INEXACT, etc, to match the status register and not include <fenv.h>.. 2024-02-03 John David Anglin <danglin@gcc.gnu.org> libatomic/ChangeLog: PR target/59778 * configure.tgt (hppa*): Set ARCH. * config/pa/fenv.c: New file.
At present, Evaluation of both `has_lse2(hwcap)' and `has_lse128(hwcap)' may require issuing an `mrs' instruction to query a system register. This instruction, when issued from user-space results in a trap by the kernel which then returns the value read in by the system register. Given the undesirable nature of the computational expense associated with the context switch, it is important to implement mechanisms to, wherever possible, forgo the operation. In light of this, given how other architectural requirements serving as prerequisites have long been assigned HWCAP bits by the kernel, we can inexpensively query for their availability before attempting to read any system registers. Where one of these early tests fail, we can assert that the main feature of interest (be it LSE2 or LSE128) cannot be present, allowing us to return from the function early and skip the unnecessary expensive kernel-mediated access to system registers. libatomic/ChangeLog: * config/linux/aarch64/host-config.h (has_lse2): Add test for LSE. (has_lse128): Add test for LSE2.
The armv9.4-a architectural revision adds three new atomic operations associated with the LSE128 feature: * LDCLRP - Atomic AND NOT (bitclear) of a location with 128-bit value held in a pair of registers, with original data loaded into the same 2 registers. * LDSETP - Atomic OR (bitset) of a location with 128-bit value held in a pair of registers, with original data loaded into the same 2 registers. * SWPP - Atomic swap of one 128-bit value with 128-bit value held in a pair of registers. It is worth noting that in keeping with existing 128-bit atomic operations in `atomic_16.S', we have chosen to merge certain less-restrictive orderings into more restrictive ones. This is done to minimize the number of branches in the atomic functions, minimizing both the likelihood of branch mispredictions and, in keeping code small, limit the need for extra fetch cycles. Past benchmarking has revealed that acquire is typically slightly faster than release (5-10%), such that for the most frequently used atomics (CAS and SWP) it makes sense to add support for acquire, as well as release. Likewise, it was identified that combining acquire and release typically results in little to no penalty, such that it is of negligible benefit to distinguish between release and acquire-release, making the combining release/acq_rel/seq_cst a worthwhile design choice. This patch adds the logic required to make use of these when the architectural feature is present and a suitable assembler available. In order to do this, the following changes are made: 1. Add a configure-time check to check for LSE128 support in the assembler. 2. Edit host-config.h so that when N == 16, nifunc = 2. 3. Where available due to LSE128, implement the second ifunc, making use of the novel instructions. 4. For atomic functions unable to make use of these new instructions, define a new alias which causes the _i1 function variant to point ahead to the corresponding _i2 implementation. libatomic/ChangeLog: * Makefile.am (AM_CPPFLAGS): add conditional setting of -DHAVE_FEAT_LSE128. * acinclude.m4 (LIBAT_TEST_FEAT_AARCH64_LSE128): New. * config/linux/aarch64/atomic_16.S (LSE128): New macro definition. (libat_exchange_16): New LSE128 variant. (libat_fetch_or_16): Likewise. (libat_or_fetch_16): Likewise. (libat_fetch_and_16): Likewise. (libat_and_fetch_16): Likewise. * config/linux/aarch64/host-config.h (IFUNC_COND_2): New. (IFUNC_NCOND): Add operand size checking. (has_lse2): Renamed from `ifunc1`. (has_lse128): New. (HWCAP2_LSE128): Likewise. * configure.ac: Add call to LIBAT_TEST_FEAT_AARCH64_LSE128. * configure (ac_subst_vars): Regenerated via autoreconf. * Makefile.in: Likewise. * auto-config.h.in: Likewise.
With support for new atomic features in Armv9.4-a being indicated by
HWCAP2 bits, Libatomic's ifunc resolver must now query its second
argument, of type __ifunc_arg_t*.
We therefore make this argument known to libatomic, allowing us to
query hwcap2 bits in the following manner:
bool
resolver (unsigned long hwcap, const __ifunc_arg_t *features);
{
return (features->hwcap2 & HWCAP2_<FEAT_NAME>);
}
libatomic/ChangeLog:
* config/linux/aarch64/host-config.h (__ifunc_arg_t):
Conditionally-defined if `sys/ifunc.h' not found.
(_IFUNC_ARG_HWCAP): Likewise.
(IFUNC_COND_1): Pass __ifunc_arg_t argument to ifunc.
(ifunc1): Modify function signature to accept __ifunc_arg_t
argument.
* configure.tgt: Add second `const __ifunc_arg_t *features'
argument to IFUNC_RESOLVER_ARGS.
The introduction of further architectural-feature dependent ifuncs for AArch64 makes hard-coding ifunc `_i<n>' suffixes to functions cumbersome to work with. It is awkward to remember which ifunc maps onto which arch feature and makes the code harder to maintain when new ifuncs are added and their suffixes possibly altered. This patch uses pre-processor `#define' statements to map each suffix to a descriptive feature name macro, for example: #define LSE(NAME) NAME##_i1 Where we wish to generate ifunc names with the pre-processor's token concatenation feature, we add a level of indirection to previous macro calls. If before we would have had`MACRO(<name>_i<n>)', we now have `MACRO_FEAT(name, feature)'. Where we wish to refer to base functionality (i.e., functions where ifunc suffixes are absent), the original `MACRO(<name>)' may be used to bypass suffixing. Consequently, for base functionality, where the ifunc suffix is absent, the macro interface remains the same. For example, the entry and endpoints of `libat_store_16' remain defined by: ENTRY (libat_store_16) and END (libat_store_16) For the LSE2 implementation of the same 16-byte atomic store, we now have: ENTRY_FEAT (libat_store_16, LSE2) and END_FEAT (libat_store_16, LSE2) For the aliasing of function names, we define the following new implementation of the ALIAS macro: ALIAS (FN_BASE_NAME, FROM_SUFFIX, TO_SUFFIX) Defining the `CORE(NAME)' macro to be the identity operator, it returns the base function name unaltered and allows us to alias target-specific ifuncs to the corresponding base implementation. For example, we'd alias the LSE2 `libat_exchange_16' to it base implementation with: ALIAS (libat_exchange_16, LSE2, CORE) libatomic/ChangeLog: * config/linux/aarch64/atomic_16.S (CORE): New macro. (LSE2): Likewise. (ENTRY_FEAT): Likewise. (ENTRY_FEAT1): Likewise. (END_FEAT): Likewise. (END_FEAT1): Likewise. (ALIAS): Modify macro to take in `arch' arguments. (ALIAS1): New.