From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11566 invoked from network); 25 May 2023 14:05:19 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 25 May 2023 14:05:19 -0000 Received: (qmail 22173 invoked by uid 550); 25 May 2023 14:05:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 22131 invoked from network); 25 May 2023 14:05:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version; bh=KsAUpveM/bVRzRQNe2C/GxChyv2uehhT9Qu1UwKP270=; b=V+JY3XXIv6xAMdxB/FBTtAQJ6eUQGw8zRSDeXhMSAI3bPK8FGpvL5QK1 ZKBtz4GKnRDiQxof8Qjtq/vlr1NfSrwX6E35eBcZrXjoIu27SussHAnx0 w5iCAKFj4samiH9XeZuHZq02TDfFLNXe5V3txfn4Dmhwizhtu/Rx3KbDs g=; Authentication-Results: mail3-relais-sop.national.inria.fr; dkim=none (message not signed) header.i=none; spf=SoftFail smtp.mailfrom=jens.gustedt@inria.fr; dmarc=fail (p=none dis=none) d=inria.fr X-IronPort-AV: E=Sophos;i="6.00,191,1681164000"; d="scan'208";a="57001894" Date: Thu, 25 May 2023 16:05:01 +0200 From: =?UTF-8?B?SuKCkeKCmeKCmw==?= Gustedt To: Rich Felker Cc: musl@lists.openwall.com Message-ID: <20230525160501.787872b2@inria.fr> In-Reply-To: <20230525130723.GH4163@brightrain.aerifal.cx> References: <1fe28ea2525f112264a1a819d8ce50a97504ab8b.1684932892.git.Jens.Gustedt@inria.fr> <20230524212835.GC4163@brightrain.aerifal.cx> <20230525111653.4b0175d3@inria.fr> <20230525130723.GH4163@brightrain.aerifal.cx> Organization: inria.fr X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.33; x86_64-pc-linux-gnu) X-Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAACRQTFRFERslNjAsLTE9Ok9wUk9TaUs8iWhSrYZkj42Rz6aD3sGZ MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/IX71uAw+tFR9vJ+6tIvie6i"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: Re: [musl] [C23 new stdlib 2/4] C23: add the memalignment function --Sig_/IX71uAw+tFR9vJ+6tIvie6i Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable on Thu, 25 May 2023 09:07:23 -0400 you (Rich Felker ) wrote: > > So you want me to use the ctz and clz interfaces from the internal > > atomics for the implementation of ? Are they not overkill > > for this simple purpose? (I mean they are meant to be atomic, > > arent't they?) =20 >=20 > No, I think you're mixing up code which is part of musl and code which > is (included as) part of the application. atomic.h is a musl > implementation detail and is not even present for application code > included from stdbit.h to use. I am not clear to which question you are answering "no". Fact is that these functions are used for `ffs` and friends, so they are the natural candidates to base the implementation upon. (`ffs` cannot be used directly because they have intefaces with signed integers.) I'd very much like to avoid to reinvent the wheel, here, and in the internal code that I have looked at I have not detected much which would be specific for atomics. But maybe I am overlooking something, thus the question. > See NRK's follow-up. If pure header-only implementations of these > interfaces met the requirements of the standard, I could see a good > argument for having implementations there. But if they require > external functions, I'm not clear on why it makes sense to implement > inline versions in the headers rather than just letting the compiler > do its own transformations to inline if/when it wants. This was a path > glibc went down a long time ago with "bits/string2.h", putting gobs of > attempted-optimized code in public headers that was suppressing gcc's > builtin, much better optimizations for the same functions via its > __builtin_*. I don't think we should repeat that. Yes, thanks, I understand that strategy much better now. Thanks J=E2=82=91=E2=82=99=E2=82=9B --=20 :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Universit=C3=A9 de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: =E2=98=8E +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt :: --Sig_/IX71uAw+tFR9vJ+6tIvie6i Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSN9stI2OFN1pLljN0P0+hp2tU34gUCZG9rDgAKCRAP0+hp2tU3 4kQ5AKCFOIJAr7hjl8TIMe8kJOgrEoDIsQCeJ8GXRFldtArWsFX62UOzFy/Ggj8= =CyTB -----END PGP SIGNATURE----- --Sig_/IX71uAw+tFR9vJ+6tIvie6i--