From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129723 invoked by alias); 19 Apr 2016 22:21:41 -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 129714 invoked by uid 89); 19 Apr 2016 22:21:40 -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=Hx-languages-length:1789, dropping X-HELO: smtp.gentoo.org Date: Tue, 19 Apr 2016 22:21:00 -0000 From: Mike Frysinger To: Wilco Dijkstra Cc: 'GNU C Library' , nd Subject: Re: [PATCH] Use strlen when searching for a nul char Message-ID: <20160419222134.GQ5369@vapier.lan> Mail-Followup-To: Wilco Dijkstra , 'GNU C Library' , nd References: <20160419175706.GI5369@vapier.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ScBGguMCFzdFq7Io" Content-Disposition: inline In-Reply-To: X-SW-Source: 2016-04/txt/msg00475.txt.bz2 --ScBGguMCFzdFq7Io Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1765 On 19 Apr 2016 22:03, Wilco Dijkstra wrote: > Mike Frysinger wrote: > > On 25 Feb 2016 13:04, Wilco Dijkstra wrote: > >> Remove the strchr (s, '\0') to rawmemchr optimization as using rawmemc= hr is > >> a bad idea - I have a patch to add strchr (s, '\0') -> strlen to GCC7. > >> Like strchr (s, '\0'), rawmemchr (s, '\0') appears a common idiom for = finding > >> the end of a string, however it is not the most efficient way of doing= so. > >> Strlen is a simpler operation which is significantly faster on larger = 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') ? >=20 > I wasn't planning to add it - GCC doesn't currently have it as a builtin = so support > would need to be added first. It's unclear how often rawmemchr is used > elsewhere and what percentage is for finding the end of a string. >=20 > > even then, since this optimization isn't showing up until GCC7, shouldn= 't > > we keep some logic here ? i.e. transform strchr/rawmemchr(s, '\0') into > > strlen before falling back ? >=20 > If it is common to use an old GCC to build a new GLIBC for a distro then = adding > strchr->strlen with a PREREQ would be useful. But if one typically first = builds GCC7 > and then GLIBC with that then it would not matter. the issue isn't what version of gcc is used to build glibc. this is an installed header, and we made guarantees that the installed headers work with much older versions of gcc at runtime. those guarantees don't hard extend to pure-optimizations, but typically we wait much longer for those versions to cycle out of common use. dropping code that requires gcc7 (which doesn't even exist yet) doesn't fall into that bucket. -mike --ScBGguMCFzdFq7Io Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFq9uAAoJEEFjO5/oN/WBrHEP/jVJNEtDYVbfL3LD5t5PaTNq XuKSnbfAzrUbSZUgqB1UyvlcjVkBIffUBhEl+SmybL9oAt0cAbCITnan1lg7gbp9 d9ChN5PVsi7ksgfnoiGp2PuYUUbZfkpoxb577ZnXZajCzLPp/vJBJyk7VOTT/S0p pRjFSX7qLUijKpTjiiRZbxTBQZWyl/d9O1UXxME1nX0+B8OKyryomviIKb7BBNRN sYmu4CwI+WhLG9DXtQJVdI8ENN3eQuU8LajCk84ssWKvZ9AI+P5lMTr7nyilOvhk 1Gc6tI6gSJ0hLAXkqdFIehGGAnYa7SxOKwNL3ORlYpoxrdaAe0WwSnYP8rf8kH1O bi2KkHg+/7tk0VWRDQrrzMMxNVNSO//P6pwXazRccmJDtqP1cXKkAlCA9wzBlEyC jJ1fxcHmKp+lnGqmP5seE/xFcJDW6YrvUnuxUPe7dvqdiLDlCRQihdDCpCdKDAgw Bw7zdHAZ1JREk6qcYaqKFQefGkcPi5CyNcZHw94yvXpztrURIG5/4kcpmBtRAkUG 81oMde3gZf3L5f5LBBwEVWAYE1E+CkKJdKof92xfeBEq8QRfeuP7zl49f4EFHf6i UWkx6kRyEZiC0RyR9On0vMslCULFuyNXZFDFvfZQ5xgZfSe19/7DISwNOJL1qygq QQkkmu6EldpwDSYE6Pa1 =SNm6 -----END PGP SIGNATURE----- --ScBGguMCFzdFq7Io--