This is the mail archive of the libc-alpha@sourceware.org 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] 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.


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