This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/4] Improve generic strspn/strcspn/strpbrk
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Thu, 31 Mar 2016 15:29:38 -0300
- Subject: Re: [PATCH 0/4] Improve generic strspn/strcspn/strpbrk
- Authentication-results: sourceware.org; auth=none
- References: <1459432863-20749-1-git-send-email-adhemerval dot zanella at linaro dot org>
Besides latest Wilco's reviews regarding the __glibc_expect for
strcspn and Richard's note about using uintptr_t instead of
size_t for pointer manipulation, is there any more review
about this set? If not I will commit it this in upcoming hours.
On 31-03-2016 11:00, Adhemerval Zanella wrote:
> Changes from previous version:
>
> * Add some optimization on strspn implementation from Wilco
> comments.
>
> * Move the inline __str{spn,cspn,brk}_* symbol from the string2.h
> header to string-inlike and added compatibility version since
> they will not be generated anymore.
>
> ---
>
>
> This is a followup on previous Wilco patch [1] to optimize strcspn
> that also optimizes the generic strspn and strpbrk. I used the
> same strategy Wilco has used on strcspn for strspn and rewrote
> strpbrk to just use strcspn instead.
>
> I also tried to play with compiler options to check if it could
> omit the memset call generation when initializing the lookup
> table, but without success. This is a similar strategy I used
> on powerpc64 str{c}spn optimization.
>
> Wilco initial approach was to remove the __strcspn_c{1,2,3}
> inline function in string2.h header, however they are part of
> ABI (to support compilers that do not inline the calls) and it
> is not safe to remove then. I have added it back, although the
> strcspn new macro does not uses them and I also used the same
> strategy for both strspn and strpbrk.
>
> Performance-wise the algorithm is similar with current optimized
> assembly one already in GLIBC (x86 and powerpc). In fact, for
> powerpc64 the algorithm performance is similar to assembly
> routines which lead me to remove them. i686 default one
> is slight faster, while the SSE4.1 variant shows much better
> performance (through the use of SIMD instructions).
>
> [1] https://sourceware.org/ml/libc-alpha/2016-01/msg00173.html
>
> Adhemerval Zanella (3):
> Improve generic strspn performance
> Improve generic strpbrk performance
> Remove powerpc64 strspn, strcspn, and strpbrk implementation
>
> Wilco Dijkstra (1):
> Improve generic strcspn performance
>
> ChangeLog | 46 ++++++++
> string/Versions | 2 +
> string/bits/string2.h | 208 ++----------------------------------
> string/strcspn.c | 44 ++++++--
> string/string-inlines.c | 97 +++++++++++++++++
> string/strpbrk.c | 12 +--
> string/strspn.c | 54 +++++++---
> sysdeps/i386/string-inlines.c | 19 +---
> sysdeps/powerpc/powerpc64/strcspn.S | 127 ----------------------
> sysdeps/powerpc/powerpc64/strpbrk.S | 135 -----------------------
> sysdeps/powerpc/powerpc64/strspn.S | 144 -------------------------
> 11 files changed, 233 insertions(+), 655 deletions(-)
> delete mode 100644 sysdeps/powerpc/powerpc64/strcspn.S
> delete mode 100644 sysdeps/powerpc/powerpc64/strpbrk.S
> delete mode 100644 sysdeps/powerpc/powerpc64/strspn.S
>