This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH, AArch64] Add optimized strchrnul
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Kyle McMartin <kmcmarti at redhat dot com>
- Cc: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, Richard Earnshaw <rearnsha at arm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Tue, 9 Dec 2014 14:38:11 -0800
- Subject: Re: [PATCH, AArch64] Add optimized strchrnul
- Authentication-results: sourceware.org; auth=none
- References: <539AD11E dot 50507 at arm dot com> <CAFqB+PyiWb1Bj+UJa2HRvyCMhn-H57r3Wn05mHpnOn1n_qhzrQ at mail dot gmail dot com> <20141203174546 dot GG4170 at redacted dot bos dot redhat dot com>
On Wed, Dec 3, 2014 at 9:45 AM, Kyle McMartin <firstname.lastname@example.org> wrote:
> On Wed, Nov 05, 2014 at 02:02:22PM +0000, Marcus Shawcroft wrote:
>> On 13 June 2014 11:23, Richard Earnshaw <email@example.com> wrote:
>> > Here is an optimized implementation of __strchrnul. The simplification
>> > that we don't have to track precisely why the loop terminates (match or
>> > end-of-string) means we have to do less work in both setup and the core
>> > inner loop. That means this should never be slower than strchr.
>> > As with strchr, the use of LD1 means we do not need different versions
>> > for big-/little-endian.
>> > <date> Richard Earnshaw <firstname.lastname@example.org>
>> > * sysdeps/aarch64/strchrnul.S: New file.
>> Committed. + NEWS entry. /Marcus
> Hrm, I've bisected this commit as the cause of localedef segfaulting as
> part of install-locales... it ends up crashing weirdly inside of
> vsprintf's internals. Have either of you seen anything similar?
I just ran into this with an ILP32 compiled glibc (with thunderX
tuning and some extra patches) where printf was crashing. The problem
is v15 is being used but it is a callee saved register. Here is the
documentation from the ABI:
Registers v8-v15 must be preserved by a callee across subroutine
calls; the remaining registers (v0-v7, v16-v31)
do not need to be preserved (or should be preserved by the caller).
> regards, Kyle