This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Neon assumption in strchrnul and strrchr

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]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]