From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84775 invoked by alias); 19 Apr 2016 21:23:25 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 84727 invoked by uid 89); 19 Apr 2016 21:23:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.gentoo.org Date: Tue, 19 Apr 2016 21:23:00 -0000 From: Mike Frysinger To: Adhemerval Zanella Cc: libc-alpha@sourceware.org Subject: Re: [PATCH] Use strlen when searching for a nul char Message-ID: <20160419212320.GP5369@vapier.lan> Mail-Followup-To: Adhemerval Zanella , libc-alpha@sourceware.org References: <20160419175706.GI5369@vapier.lan> <571694A4.4020603@linaro.org> <20160419205116.GO5369@vapier.lan> <57169CB3.90200@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HtrkgkD3uBADSQLK" Content-Disposition: inline In-Reply-To: <57169CB3.90200@linaro.org> X-SW-Source: 2016-04/txt/msg00473.txt.bz2 --HtrkgkD3uBADSQLK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1910 On 19 Apr 2016 18:01, Adhemerval Zanella wrote: > On 19-04-2016 17:51, Mike Frysinger wrote: > > On 19 Apr 2016 17:27, Adhemerval Zanella wrote: > >> On 19-04-2016 14:57, Mike Frysinger wrote: > >>> On 25 Feb 2016 13:04, Wilco Dijkstra wrote: > >>>> Remove the strchr (s, '\0') to rawmemchr optimization as using rawme= mchr is > >>>> a bad idea - I have a patch to add strchr (s, '\0') -> strlen to GCC= 7. > >>>> Like strchr (s, '\0'), rawmemchr (s, '\0') appears a common idiom fo= r finding > >>>> the end of a string, however it is not the most efficient way of doi= ng so. > >>>> Strlen is a simpler operation which is significantly faster on large= r inputs > >>>> (eg. on x86 strlen is 50% faster than rawmemchr on strings of 1KB). > >>> > >>> will there be a change in GCC to also detect rawmemchr(s,'\0') ? > >>> > >>> even then, since this optimization isn't showing up until GCC7, shoul= dn't > >>> we keep some logic here ? i.e. transform strchr/rawmemchr(s, '\0') i= nto > >>> strlen before falling back ? > >> > >> Personally I am not very found on the string2.h header and its intrins= ic logic, > >> which contains optimization logic that might not be true depending of = the > >> architecture string optimization. > >> > >> Also for the specific optimization does we really need to keep pushing= for=20 > >> these specific inline implementations? I would prefer a much simple st= ring2.h > >> header than a convoluted one we have today. > >=20 > > i don't have a real opinion on keeping it or just tossing the whole > > thing out. but if we keep it, i think we should be adding the bits > > that make sense (like my question above) rather than half-assing it. >=20 > My idea is to cleanup the header bit a bit until we could just removei > it. That's why I would prefer to not add any more optimization bits > on it. if everyone agrees on that direction, then slowly culling it WFM -mike --HtrkgkD3uBADSQLK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFqHIAAoJEEFjO5/oN/WB0bAQALTzJEbdlvfMaUtF72kPbm3f BEwcZ5cOG1eVZ2BHYlsyqrcAI08MTT+v48aGqmFzIfhptwN8LPbClbWvg12Z0Ryh wOxY85KeaIr/MWjCqVpX4KutfVnYCPp9qqpF5n0tEzIRRE1TkQR+jpP+r1DAOIq6 yC6b/TiIEyicvQhPNSt0dQZWITDrD1DYp+NhO/kdvxZRqaggx8W4j4isBDnE9xBo y/xe8HOB+ehNyziCkWSKNpkXeoOAugpwTiAJytaP1dI5K5HgIBLcuPutTrzr7/sw IdPJ42bskuNlRZ9okhKZbbA964ZP9zJ2aZcJcEqZhoSf8RsfR8aMFefbv4DiVciN ledDK1/pH7aQFAfsqTMt8ckBBXrVL9bPTkQx3WOmEoh1cT2rDiCN5Zjv57cg4LwG xiluw58kVOFnCpODrcQgpnx3VWrk5mLg/Bx+ZP+R9NFVImzRJ9Zc3bL6xMiSo1Th Ho3VwhseyziW64PUC2YuV3o76dKVvvQrfkiV81Y6zWRNAP5MUIHxFaJoWy1p6+u7 3+hl4qqUGXe3S2wa4pBuJN/FK+sQnFSCP4Vt94GAtsTmFGb/nP9ZMFdiwI4XEjGh 1b1LwixGuOEjo/b0EAiDvrSCs8ncVWOZGvJlBdW5K45hdn5I+gmpPqnLahYQpRiX ny0U0Lc6TAOCms36D0Mj =P2l4 -----END PGP SIGNATURE----- --HtrkgkD3uBADSQLK--