From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38748 invoked by alias); 19 Apr 2016 20:51:29 -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 38230 invoked by uid 89); 19 Apr 2016 20:51:28 -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:1546, Personally X-HELO: smtp.gentoo.org Date: Tue, 19 Apr 2016 20:51: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: <20160419205116.GO5369@vapier.lan> Mail-Followup-To: Adhemerval Zanella , libc-alpha@sourceware.org References: <20160419175706.GI5369@vapier.lan> <571694A4.4020603@linaro.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7tuoKvP21MOB3sJS" Content-Disposition: inline In-Reply-To: <571694A4.4020603@linaro.org> X-SW-Source: 2016-04/txt/msg00470.txt.bz2 --7tuoKvP21MOB3sJS Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 1525 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 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). > >=20 > > will there be a change in GCC to also detect rawmemchr(s,'\0') ? > >=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 > Personally I am not very found on the string2.h header and its intrinsic = logic, > which contains optimization logic that might not be true depending of the > architecture string optimization. >=20 > Also for the specific optimization does we really need to keep pushing fo= r=20 > these specific inline implementations? I would prefer a much simple strin= g2.h > header than a convoluted one we have today. 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. -mike --7tuoKvP21MOB3sJS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXFppDAAoJEEFjO5/oN/WBoLcQAJWYLjVmxm4wpe7IAFKqGV6q w/XRbFsffp/6ZKm+QlviJywAixj5CDuCA9tFznWA+hEBhhZbpl4z0gGfReWrku67 lavD8tZoWYyJjxU6LrOP405XIPumoUgNmkWFfI/slAFOZ5z0fw2XD77BTxZYP9oD OYChWvQYIDIGDL6IWRs3LpUyPbnQdUdpqfv7sHYpy8GjkF+4BduRFMChtPs8+ZXn TLUSZGez7RrjtNq8JT3eK2lbgrQzvEtvj1tXJfWIH0AYxpM+13AmtrTy9eDTCQ3u p1ofjVi4tLQMKYoYs825JKbFigpJAfzsmxI3tTZV1BFDEQZYrhO3o4aEDglQfiFh XAL8A0yeEYbsSb0l63eZ6UO85yxeUi7w09OZjkw/+9j0EdOzeent4PISokKbfJw8 PpL48PJKpU0aG6vfvR1ZMpstDSUBKrg3PFDsky2JL0thOpiQdoYYybvwvRQawm9V h8HknYWE8lExfrvw0w+mGSaPPvfdhCJBXnH/GAwNo5YKbp0pTVwtSqZGz2bqklt2 ICuViJ9PgH3jqJ5hl4cCXyHkCQw+4LRImf3zmlRaTQcJDL9lSA9O2To3dmjehIrO 1ge5nzWrGht3kk5lny16GOcdtv1Lo6VThmFNl/HAgGt4dHnJBMkDdjPVA24ACZuB WveXbLYXMWPcamWqZrF1 =WjR+ -----END PGP SIGNATURE----- --7tuoKvP21MOB3sJS--