This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH, ARM] Optimise memchr for NEON-enabled processors
- From: Prakhar Bahuguna <prakhar dot bahuguna at arm dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, nd at arm dot com
- Date: Tue, 13 Jun 2017 17:11:18 +0100
- Subject: Re: [PATCH, ARM] Optimise memchr for NEON-enabled processors
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Prakhar dot Bahuguna at arm dot com;
- Nodisclaimer: True
- References: <20170613092505.rxuxbujpgfq6fbqo@e107464-lin.cambridge.arm.com> <alpine.DEB.2.20.1706131420540.11434@digraph.polyomino.org.uk>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 13/06/2017 14:22:52, Joseph Myers wrote:
> On Tue, 13 Jun 2017, Prakhar Bahuguna wrote:
>
> > Testing done: Ran regression tests for arm-none-linux-gnueabihf as well as a
> > full toolchain bootstrap. Benchmark tests were ran on ARMv7-A and ARMv8-A
> > hardware targets.
>
> It's important to test string functions for both endiannesses, since they
> can easily have endian-specific bugs. You should be able to run string/
> tests for big-endian with QEMU userspace emulation, for example, if you
> don't have an actual big-endian system to run tests on (some parts of the
> glibc testsuite, such as threading tests, may have problems with QEMU
> userspace emulation, but for string tests it should be fine).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
This implementation was tested for big-endian targets as well (via qemu) and it
also passed regression tests for armeb-none-linux-gnueabihf. No bootstrap or
benchmarking was performed for big-endian though.
--
Prakhar Bahuguna