During ellipsis processing the collation cursor was not correctly
moved to the end of the ellipsis after processing.
The code inserted the new entry after the cursor, but before the
real end of the ellipsis:
[cursor]
... element_t <-> element_t <-> element_t <-> element_t
"<U0000>" "<U0001>" "<U007F>"
startp endp
At the end of the function we have:
[cursor]
... element_t <-> element_t <-> element_t
"<U007E>" "<U007F>"
endp
The cursor should be pointing at endp, the last element in the
doubly-linked list, otherwise when execution returns to the
caller we will start inserting the next line after <U007E>.
Subsequent operations end up unlinking the ellipsis end entry or
just leaving it in the list dangling from the end. This kind of
dangling is immediately visible in C.UTF-8 with the following
sorting from strcoll:
<U0010FFFF>
<U0000FFFF>
<U000007FF>
<U0000007F>
With the cursor correctly adjusted the end entry is correctly given
the right location and thus the right weight.
Retested and no regressions on x86_64 and i686.
Co-authored-by: Carlos O'Donell <carlos@redhat.com>
No bug. This commit optimizes strchr-evex.S. The optimizations are
mostly small things such as save an ALU in the alignment process,
saving a few instructions in the loop return. The one significant
change is saving 2 instructions in the 4x loop. test-strchr,
test-strchrnul, test-wcschr, and test-wcschrnul are all passing.
Signed-off-by: Noah Goldstein <goldstein.w.n@gmail.com>
No bug. This commit optimizes strchr-avx2.S. The optimizations are all
small things such as save an ALU in the alignment process, saving a
few instructions in the loop return, saving some bytes in the main
loop, and increasing the ILP in the return cases. test-strchr,
test-strchrnul, test-wcschr, and test-wcschrnul are all passing.
Signed-off-by: Noah Goldstein <goldstein.w.n@gmail.com>
For some architectures, the two functions are aliased, so these
symbols need to be moved at the same time.
The symbols were moved using scripts/move-symbol-to-libc.py.
And pthread_mutexattr_setkind_np as a compatibility symbol.
__pthread_mutexattr_settype is used in mtx_init from libpthread,
so this commit adds a GLIBC_2.34 symbol version for it.
The symbols were moved using scripts/move-symbol-to-libc.py.
__pthread_mutexattr_init cannot be be made a compat symbol because
it is used in mtx_init, which is still in libpthread.
The symbols were moved using scripts/move-symbol-to-libc.py.
And pthread_mutexattr_getkind_np as a compatibility symbol.
(There is no declaration in <pthread.h>, so there is no need
to add an alias or a deprecation warning there.)
The symbols were moved using scripts/move-symbol-to-libc.py.
And __pthread_mutexattr_destroy as a compat symbol (so no
GLIBC_2.34 symbol version is added for it).
The symbols were moved using scripts/move-symbol-to-libc.py.
The symbols were moved using scripts/move-symbol-to-libc.py.
__pthread_mutex_trylock is used to implement mtx_timedlock,
which still resides in libpthread, so add a GLIBC_2.34 version
for it, to match the existing GLIBC_2.0 version.
The symbols were moved using scripts/move-symbol-to-libc.py.
The symbol aliasing follows pthread_cond_timedwait et al.
Missing hidden prototypes had to be added to nptl/pthreadP.h
for consistency.
Improvements compared to POWER9 version:
1. Take into account first 16B comparison for aligned strings
The previous version compares the first 16B and increments r4 by the number
of bytes until the address is 16B-aligned, then starts doing aligned loads at
that address. For aligned strings, this causes the first 16B to be compared
twice, because the increment is 0. Here we calculate the next 16B-aligned
address differently, which avoids that issue.
2. Use simple comparisons for the first ~192 bytes
The main loop is good for big strings, but comparing 16B each time is better
for smaller strings. So after aligning the address to 16 Bytes, we check
more 176B in 16B chunks. There may be some overlaps with the main loop for
unaligned strings, but we avoid using the more aggressive strategy too soon,
and also allow the loop to start at a 64B-aligned address. This greatly
benefits smaller strings and avoids overlapping checks if the string is
already aligned at a 64B boundary.
3. Reduce dependencies between load blocks caused by address calculation on loop
Doing a precise time tracing on the code showed many loads in the loop were
stalled waiting for updates to r4 from previous code blocks. This
implementation avoids that as much as possible by using 2 registers (r4 and
r5) to hold addresses to be used by different parts of the code.
Also, the previous code aligned the address to 16B, then to 64B by doing a
few 48B loops (if needed) until the address was aligned. The main loop could
not start until that 48B loop had finished and r4 was updated with the
current address. Here we calculate the address used by the loop very early,
so it can start sooner.
The main loop now uses 2 pointers 128B apart to make pointer updates less
frequent, and also unrolls 1 iteration to guarantee there is enough time
between iterations to update the pointers, reducing stalled cycles.
4. Use new P10 instructions
lxvp is used to load 32B with a single instruction, reducing contention in
the load queue.
vextractbm allows simplifying the tail code for the loop, replacing
vbpermq and avoiding having to generate a permute control vector.
Reviewed-by: Paul E Murphy <murphyp@linux.ibm.com>
Reviewed-by: Raphael M Zinsly <rzinsly@linux.ibm.com>
Reviewed-by: Lucas A. M. Magalhaes <lamm@linux.ibm.com>
The symbol was moved using scripts/move-symbol-to-libc.py.
There is no new symbol version because of the compatibility symbol
status. The __pthread_atfork reference in nptl/Versions was unused.
This is required for GCC versions before 10 which default to -fcommon.
Fixes commit 442e8a40da ("nptl: Move part
of TCB initialization from libpthread to __tls_init_tp").
The signal handler is exported as __nptl_setxid_sighandler, so
that the libpthread initialization code can install it. This
is sufficient for now because it is guarantueed to happen before
the first pthread_create call.
Onl pthread_cond_clockwait did not have a forwarder, so it needs
a new symbol version.
Some complications arise due to the need to supply hidden aliases,
GLIBC_PRIVATE exports (for the C11 condition variable implementation
that still remains in libpthread) and 64-bit time_t stubs.
pthread_cond_broadcast, pthread_cond_signal, pthread_cond_timedwait,
pthread_cond_wait, pthread_cond_clockwait have been moved using
scripts/move-symbol-to-libc.py.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This is complicated because of a second compilation of
nptl/pthread_mutex_lock.c via nptl/pthread_mutex_cond_lock.c.
PTHREAD_MUTEX_VERSIONS is introduced to suppress symbol versions
in that case.
The symbols __pthread_mutex_lock, __pthread_mutex_unlock,
__pthread_mutex_init, __pthread_mutex_destroy, pthread_mutex_lock,
pthread_mutex_unlock, pthread_mutex_init, pthread_mutex_destroy
have been moved using scripts/move-symbol-to-libc.py.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The current approach is to do this optimizations at a higher level,
in generic code, so that single-threaded cases can be specifically
targeted.
Furthermore, using IS_IN (libc) as a compile-time indicator that
all locks are private is no longer correct once process-shared lock
implementations are moved into libc.
The generic <lowlevellock.h> is not compatible with assembler code
(obviously), so it's necessary to remove two long-unused #includes.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This is optimization is similar in spirit to the SINGLE_THREAD_P check
in the malloc implementation. Doing this in generic code allows us
to prioritize those cases which are likely to occur in single-threaded
programs (normal and recursive mutexes).
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This is in preparation of moving the mutex code into libc.
__pthread_tunables_init is now called via __pthread_early_init.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
The forwarders were only used internally, so new symbol versions
are needed. All symbols are moved at once because the forwarders
are no-ops if libpthread is not loaded, leading to inconsistencies
in case of a partial migration.
The symbols __pthread_rwlock_rdlock, __pthread_rwlock_unlock,
__pthread_rwlock_wrlock, pthread_rwlock_rdlock,
pthread_rwlock_unlock, pthread_rwlock_wrlock have been moved using
scripts/move-symbol-to-libc.py.
The __ symbol variants are turned into compat symbols, which is why they
do not receive a GLIBC_2.34 version.
The symbol was moved using scripts/move-symbol-to-libc.py.
tss_delete (still in libpthread) uses the __pthread_key_create
alias, so that is now exported under GLIBC_PRIVATE.