On Tue, Jun 12, 2018 at 07:01:59PM +0200, Christophe LEROY wrote:
>
>
> Le 12/06/2018 à 16:53, Segher Boessenkool a écrit :
> >On Tue, Jun 12, 2018 at 09:14:53AM +, Christophe Leroy wrote:
> >>---
> >>Not tested on PPC64.
> >
> >It won't be acceptable until that happens. It also is likely qu
Christophe LEROY writes:
> Le 12/06/2018 à 16:53, Segher Boessenkool a écrit :
>> On Tue, Jun 12, 2018 at 09:14:53AM +, Christophe Leroy wrote:
>>> ---
>>> Not tested on PPC64.
>>
>> It won't be acceptable until that happens. It also is likely quite bad
>> performance on all 64-bit CPUs fro
Le 12/06/2018 à 16:53, Segher Boessenkool a écrit :
On Tue, Jun 12, 2018 at 09:14:53AM +, Christophe Leroy wrote:
---
Not tested on PPC64.
It won't be acceptable until that happens. It also is likely quite bad
performance on all 64-bit CPUs from the last fifteen years or so. Or you
di
On Tue, Jun 12, 2018 at 09:14:53AM +, Christophe Leroy wrote:
> ---
> Not tested on PPC64.
It won't be acceptable until that happens. It also is likely quite bad
performance on all 64-bit CPUs from the last fifteen years or so. Or you
did nothing to prove otherwise, at least.
> + * Algorigt
The generic implementation of strlen() reads strings byte per byte.
This patch implements strlen() in assembly based on a read of entire
words, in the same spirit as what some other arches and glibc do.
On a 8xx the time spent in strlen is reduced by 3/4 for long strings.
strlen() selftest on an
