This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Neon assumption in strchrnul and strrchr
- From: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>, Richard Earnshaw <rearnsha at arm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 2 Feb 2016 16:45:28 +0000
- Subject: Re: Neon assumption in strchrnul and strrchr
- Authentication-results: sourceware.org; auth=none
- References: <20160202153613 dot GG17552 at devel dot intra dot reserved-bit dot com>
On 02/02/16 15:36, Siddhesh Poyarekar wrote:
> Hi Richard,
>
> I came across the aarch64 implementations of strrchr and strchrnul and
> noticed that they assume that advsimd is available. While advsimd is
> standard in armv8-a, it seems wrong given that one could compiler code
> using -mcpu=cortex-a57-nosimd. Any code that is statically compiled
> in this manner would assume that the binary never uses neon, but if
> the code calls any of these two functions, that assumption would be
> invalid.
>
> Shouldn't this be considered a bug and maybe a default implementation
> be put in that does not make this assumption and sticks to using the
> standard instruction set?
>
> See also the discussion on lkml[1] on emulating mrs, which should
> allow us to deploy such advsimd-based routines from an ifunc in
> future.
>
> Siddhesh
>
> [1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/472258
>
For user space we assume that both FP and Advanced SIMD (Neon) are
always available. To assume otherwise would require a new ABI since
Neon operations are required for long-double data types (128-bit FP).
As such, I think it's perfectly reasonable for library code to use Neon
whenever appropriate.
Kernel code, of course, has to be more careful since it needs to ensure
that the user-space context is correctly saved.
R.