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.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_LOW,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9030 invoked from network); 25 May 2023 13:07:39 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 25 May 2023 13:07:39 -0000 Received: (qmail 23773 invoked by uid 550); 25 May 2023 13:07:36 -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 23741 invoked from network); 25 May 2023 13:07:35 -0000 Date: Thu, 25 May 2023 09:07:23 -0400 From: Rich Felker To: =?utf-8?B?SuKCkeKCmeKCmw==?= Gustedt Cc: musl@lists.openwall.com Message-ID: <20230525130723.GH4163@brightrain.aerifal.cx> References: <1fe28ea2525f112264a1a819d8ce50a97504ab8b.1684932892.git.Jens.Gustedt@inria.fr> <20230524212835.GC4163@brightrain.aerifal.cx> <20230525111653.4b0175d3@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230525111653.4b0175d3@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [C23 new stdlib 2/4] C23: add the memalignment function On Thu, May 25, 2023 at 11:16:53AM +0200, Jā‚‘ā‚™ā‚› Gustedt wrote: > Rich, > > on Wed, 24 May 2023 17:28:35 -0400 you (Rich Felker ) > wrote: > > > There's a more efficient implementation of this function which does > > not depend on __builtin_ctzll (which we don't): p^(p-1)&p > > yes, nice > > If you have other such nice formulas for some of the interfaces in > , please let me know. They are hard to find in search > engines. > > For `__builtin_ctzll`, hm, I counted also to use these for the > interfaces. I think the intent of those is really to > provide instruction level support of these bit functionalities that > avoids going through function calls. > > I see that we use other quite specific builtins, such as > `__builtin_fma`. Is there a particular reason not to have the bit > level ones? That was probably an oversight. The intent of those is to expand to an fma instruction, but AIUI there's no reason the compiler isn't allowed to expand it to a call to the fma() function (like the other __builtin_* versions of standard functions). That's not really a problem here, but it *could be* in other cases where the definition may end up being circular. Really these should be cleaned up to have src/include/*.h recover some of the builtins that -ffreestanding had to suppress (to prevent circularity) where they're useful, conditional on probing for compiler support, rather than using them directly in the code. Then log, pow, and log2 could just call fma(). More importantly, a lot of memcpy/memset use could be inlined where it can't now. > 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?) 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'm not clear that there's a really good motivation for having it > > implemented in the header. It kinda falls under the "maybe do it > > because it's easy" case, but once you switch to the non-GNUC-specific > > version, it needs a static inline function to avoid multiple > > evaluation, > > I guess using `({ ... })` would also not be acceptable? It's presently outside the limited set of GNU C we use, and I'd prefer to keep it that way. > > and then it gets to the point of "this is really too much > > code to have in a header" (which is more an issue of avoiding > > "creative" content in headers than anything else). > > You probably won't like what I have now for the bit operations, then > :-( 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. Rich