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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22960 invoked from network); 27 Dec 2021 18:41:54 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Dec 2021 18:41:54 -0000 Received: (qmail 20297 invoked by uid 550); 27 Dec 2021 18:41:52 -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 20265 invoked from network); 27 Dec 2021 18:41:52 -0000 Date: Mon, 27 Dec 2021 13:41:38 -0500 From: Rich Felker To: Markus Wichmann Cc: musl@lists.openwall.com Message-ID: <20211227184137.GY7074@brightrain.aerifal.cx> References: <20211226204238.GA1949@voyager> <20211227150010.GU7074@brightrain.aerifal.cx> <20211227163056.GV7074@brightrain.aerifal.cx> <20211227180437.GE1949@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211227180437.GE1949@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] ASM-to-C conversion for i386 On Mon, Dec 27, 2021 at 07:04:37PM +0100, Markus Wichmann wrote: > On Mon, Dec 27, 2021 at 11:30:56AM -0500, Rich Felker wrote: > > One thought, and I'm not sure if this is a good idea or a bad one but > > worth discussing: > > > > Using your acos.c as an example, where you have the comment: > > > > atan2(fabs(sqrt((1-x)*(1+x))), x) > > > > That comment was copied from acos.s. In general, I have tried to > preserve comments. Except in fenv.s, where each time __hwcap was tested, > the same comment was prefixed, and its point should be coming across ten > times more easily by just creating a symbolic constant. > > > The actual code could be written as: > > > > return (double)x87_fpatan(x, x87_fabs(x87_fsqrt((1-x)*(1+x)))); > > > > with the appropriate "x87.h" defining each of these with the > > appropriate asm & constraints. This kinda makes the individual > > functions self-documenting and non-error-prone (repetition of > > error-prone constraints, especially the hidden requirement that, in > > "=t"(x), x have type long double). > > > > That's probably an even better idea than what I am currently doing: > Moving the "core" functions into a new header file (as static inline > functions), and using these in the function implementations. I could not > get all the duplication out; in some cases the duplication is only > conceptual (hypot() and hypotf() have the same idea, but it needs to be > implemented differently due to the different precisions/representations). > > I think I can combine both approaches, because what I'm doing appears to > have the effect of moving the __asm__ statements entirely out of the C > files into the new header file. And it appears that we are only using a > couple of instructions, anyway. > > Downside is that implementing > > static inline long double x87_fabs(long double x) { > __asm__("fabs" : "+t"(x)); > return x; > } > > now actually carries the connotation that the result is of > double-extended precision and needs rounding before being returned. > Unlike the current version which does not do that. However, to my > knowledge that will not actually be wrong, only slower, so a solution > that preserves the current connotations for these few instructions can > probably be considered a micro-optimization. Yes, I think the insns that can emit other precisions probably would need 3 versions, but there are very few of these -- just fabs and fmod? Rich