This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH RFC] allow inline intrinsics for __ieee754_sqrt/f
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: "jon at beniston dot com" <jon at beniston dot com>
- Cc: nd <nd at arm dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Fri, 17 Aug 2018 14:11:24 +0000
- Subject: Re: [PATCH RFC] allow inline intrinsics for __ieee754_sqrt/f
- References: <DB5PR08MB1030A1AC373164B2A2500365833D0@DB5PR08MB1030.eurprd08.prod.outlook.com>,<230a01d43630$e7522f00$b5f68d00$@beniston.com>
jon@beniston.com wrote:
>>The best option is to let the compiler inline sqrt - it knows when it is
feasible and avoids
>>having to add lots of target specific inline assembly code which is hard to
maintain.
>>
>>In GLIBC I renamed all __ieee754_sqrt(f) uses to sqrt(f) and added
-fno-math-errno
>>which allows compilers to inline sqrt on all targets. libm/common already
uses
>>-fno-math-errno, but could be used in all of libm safely.
>
> That works for most of the uses of __ieee754_sqrt, except, I think, for
> those in w_sqrt.c / wf_sqrt.c, that implement sqrt & sqrtf. If the target
> didn't have a builtin for sqrt, you'd end up with a recursive call, no?
You could add more libm/machine/*/w_sqrt.c files. These already exist
for arm and aarch64 - though they use inline assembler rather than the
obvious __builtin_sqrt.
Note that the sqrt function will never be called if you have a sqrt
instruction (even if you forget to use -fno-math-errno), so optimizing
w_sqrt.c is less important than ensuring __ieee754_sqrt gets inlined.
Wilco