From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11225
Path: news.gmane.org!.POSTED!not-for-mail
From: Jon Chesterfield <jonathanchesterfield@gmail.com>
Newsgroups: gmane.linux.lib.musl.general
Subject: Re: byteswap.h
Date: Fri, 7 Apr 2017 18:55:33 +0100
Message-ID: <CAOUYtQBkzysRAVn8K1MFm2hfYrv6DJmYQWuHGhnkprGBswf-4A@mail.gmail.com>
References: <225ea64f-f051-1a61-0ba2-db9f27d1ba68@gmail.com>
Reply-To: musl@lists.openwall.com
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=001a11c1702c087265054c975548
X-Trace: blaine.gmane.org 1491587754 23094 195.159.176.226 (7 Apr 2017 17:55:54 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Fri, 7 Apr 2017 17:55:54 +0000 (UTC)
To: musl@lists.openwall.com
Original-X-From: musl-return-11240-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 07 19:55:51 2017
Return-path: <musl-return-11240-gllmg-musl=m.gmane.org@lists.openwall.com>
Envelope-to: gllmg-musl@m.gmane.org
Original-Received: from mother.openwall.net ([195.42.179.200])
	by blaine.gmane.org with smtp (Exim 4.84_2)
	(envelope-from <musl-return-11240-gllmg-musl=m.gmane.org@lists.openwall.com>)
	id 1cwY6o-0004n5-AA
	for gllmg-musl@m.gmane.org; Fri, 07 Apr 2017 19:55:42 +0200
Original-Received: (qmail 10010 invoked by uid 550); 7 Apr 2017 17:55:46 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Original-Received: (qmail 9992 invoked from network); 7 Apr 2017 17:55:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20161025;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
        bh=RQV80VVESStZTihcX/KmsHURpQpGkL6RRh6OzUzpb1Y=;
        b=XjoeY+kFdeLa9nhmZ/jEqovDRoPBEbCNQ4tVHRRqKkeRmkBJfSH03bBso2pSjVCw4M
         Y0OS6l9ql1QOSG8RuJ3I1Zm092Yk4LSslm4jae4ivai3TeqFMb1b7vWDLeadNSC4Sy3K
         wAfIsvdCpbIQ+b3g6d/FvnLOHqB505G85cbcxu6hj8AuBNTxbTJfQyjLTSKx+xSW8GWQ
         m9eSlPXpv68l87FvIKdoBNQbYfXtQYpQ0zn+qupfU1CUmK1pHGUKxjaoZbBfk9I/EEOc
         0dc4eG212Iwsm2u4A2pL9uXGfG3QkVSoWBqLUxTe/ocpKWHfH+JULKgPFhfvc7yTXbkz
         rAjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to;
        bh=RQV80VVESStZTihcX/KmsHURpQpGkL6RRh6OzUzpb1Y=;
        b=YcNMyGZqQzBMh+D4jrO9JbMv0MZXpfj+5SHusXLO8/WnO1A6mgtlDd653aFq74AIQK
         2upOD4XI1zf+cbxCpE5DPU4USVax9y5fs9HL68w8a5LhNGhuKbYI55r//fcdleHpuQGR
         6/274+lVOtm5JXZpyJHHBcZdFM7R6ubr2pl1xO2XrsVmA1Je+B+U1Ag+YYYYYRA0GVqP
         nK++GpNei0Q4B4fJ8sutSlFTfEgYTvRvNgOaWxOdA1hxIAYCy+GtT1m0SH0wl1j2sh+T
         5oat73jY6q2FUwZ0zsQeB3zcm5JVsymFtJtFBnvHu+tKnPfNsCGQC8oNzIwYb3jSkbgW
         LtLg==
X-Gm-Message-State: AN3rC/5HwKCUn8DAETlNcsJMe2UZdgkDmVCamIaofjXpYScr8N3dUlvRQ+kYAxpvCAffWs0sbUw8u2D//OoeWA==
X-Received: by 10.157.43.82 with SMTP id f18mr6406398otd.226.1491587733938;
 Fri, 07 Apr 2017 10:55:33 -0700 (PDT)
In-Reply-To: <225ea64f-f051-1a61-0ba2-db9f27d1ba68@gmail.com>
Xref: news.gmane.org gmane.linux.lib.musl.general:11225
Archived-At: <http://permalink.gmane.org/gmane.linux.lib.musl.general/11225>

--001a11c1702c087265054c975548
Content-Type: text/plain; charset=UTF-8

Have you tested whether the intrinsics improve codegen on a recent
compiler? There's a good chance they make the code non-portable while
generating the same asm.

Jon


On 7 Apr 2017 18:53, "fab10" <0xfab10@gmail.com> wrote:

I had a look at byteswap.h and it seems to me that the code is not very
efficient. Every function in this header could be translated in a single
assembly instruction with the gcc intrinsics:

__builtin_bswap16
__builtin_bswap32
__builtin_bswap64

Is there a reason to not use these gcc intrinsics?

Bye

--001a11c1702c087265054c975548
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Have you tested whether the intrinsics improve codeg=
en on a recent compiler? There&#39;s a good chance they make the code non-p=
ortable while generating the same asm.=C2=A0<div dir=3D"auto"><br></div><di=
v dir=3D"auto">Jon</div><br><div class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On 7 Apr 2017 18:53, &quot;fab10&quot; &lt;<a href=3D"mailto:0xf=
ab10@gmail.com">0xfab10@gmail.com</a>&gt; wrote:<br type=3D"attribution"><b=
lockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">I had a look at byteswap.h and it seems to me that t=
he code is not very efficient. Every function in this header could be trans=
lated in a single assembly instruction with the gcc intrinsics:<br>
<br>
__builtin_bswap16<br>
__builtin_bswap32<br>
__builtin_bswap64<br>
<br>
Is there a reason to not use these gcc intrinsics?<br>
<br>
Bye<br>
<br>
</blockquote></div><br></div></div></div>

--001a11c1702c087265054c975548--