This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ping: [PATCH v4] faster strlen on x64


On Fri, Jun 20, 2014 at 3:33 AM, OndÅej BÃlka <neleai@seznam.cz> wrote:
> On Thu, Jun 19, 2014 at 02:59:17PM -0700, H.J. Lu wrote:
>> On Thu, Jun 19, 2014 at 2:15 PM, OndÅej BÃlka <neleai@seznam.cz> wrote:
>> > On Thu, Jun 19, 2014 at 01:43:09PM -0700, H.J. Lu wrote:
>> >> On Sun, Mar 17, 2013 at 11:42 PM, OndÅej BÃlka <neleai@seznam.cz> wrote:
>> >> > On Fri, Mar 15, 2013 at 10:29:49AM -0400, Carlos O'Donell wrote:
>> >> >> On 03/15/2013 07:49 AM, OndÅej BÃlka wrote:
>> >> >> > On Tue, Mar 12, 2013 at 09:24:07AM -0400, Carlos O'Donell wrote:
>> >> >> >> On 03/11/2013 05:15 AM, OndÅej BÃlka wrote:
>> >> >> >>> Carlos, what is you opinion?
>> >> >> >>
>> >> >> >> The patch looks good. I have one last question though.
>> >> >> >>
>> >> >> >> We remove some interesting code in the existing strlen implementations
>> >> >> >> that ensure that strlen calls from libc itself do not go through the PLT.
>> >> >> >>
>> >> >> >> Have you verified that after your changes there are no testsuite regressions
>> >> >> >> in the plt check test or that the internal calls to strlen avoid the PLT?
>> >> >> >>
>> >> >> >> OK to checkin after this additional validation with posted result.
>> >> >> >>
>> >> >> >
>> >> >> > I ran http://sourceware.org/glibc/wiki/Testing/Check-localplt
>> >> >> > elf/checklocalplt.out is empty. I guess this means no regressions.
>> >> >>
>> >> >> Correct.
>> >> >>
>> >> >> Cheers,
>> >> >> Carlos.
>> >> >
>> >> > Commited with obvious resolution of merge conflict in
>> >> > sysdeps/x86-64/multiarch/Makefile.
>> >>
>> >> This commit:
>> >>
>> >> commit 37bb363f03d75e5e6f2ca45f2c686a3a0167797e
>> >> Author: Ondrej Bilka <neleai@seznam.cz>
>> >> Date:   Mon Mar 18 07:39:12 2013 +0100
>> >>
>> >>     Faster strlen on x64.
>> >>
>> >>  sysdeps/x86_64/multiarch/Makefile                |   6 +-
>> >>  sysdeps/x86_64/multiarch/ifunc-impl-list.c       |  13 -
>> >>  sysdeps/x86_64/multiarch/strcat-sse2-unaligned.S | 232 +++++++-
>> >>  sysdeps/x86_64/multiarch/strcat-ssse3.S          | 316 ++++++++++-
>> >>  sysdeps/x86_64/multiarch/strlen-sse2-no-bsf.S    | 685 -----------------------
>> >>  sysdeps/x86_64/multiarch/strlen-sse2-pminub.S    | 259 ---------
>> >>  sysdeps/x86_64/multiarch/strlen-sse4.S           |  84 ---
>> >>  sysdeps/x86_64/multiarch/strlen.S                |  68 ---
>> >>  sysdeps/x86_64/multiarch/strnlen-sse2-no-bsf.S   |   3 -
>> >>  sysdeps/x86_64/multiarch/strnlen.S               |  57 --
>> >>  sysdeps/x86_64/strcat.S                          |   1 +
>> >>  sysdeps/x86_64/strlen.S                          | 272 ++++++---
>> >>  sysdeps/x86_64/strnlen.S                         |  67 +--
>> >>
>> >> has no ChangeLog entries.  Since it removed sysdeps/x86_64/multiarch/strlen.S,
>> >> sysdeps/x86_64/multiarch/rtld-strlen.S became unnecessary and should also
>> >> be removed.
>> >>
>> >>
>> >> --
>> >> H.J.
>> > A changelog entry is here. You cannot remove
>> > sysdeps/x86_64/multiarch/rtld-strlen.S as we cannot now use sse2 in
>> > rtld. I had patch that removed that restriction, when I return back on
>> > it and it will be commited then it could be removed.
>>
>> When sysdeps/x86_64/multiarch/rtld-strlen.S is removed,
>> sysdeps/x86_64/rtld-strlen.S is used.
>>
> Yes then its ok.

I checked in my patch to remove sysdeps/x86_64/multiarch/rtld-strlen.S.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]