This is the mail archive of the
mailing list for the glibc project.
Re: i386 fpu function rewrite
- To: Andreas Jaeger <aj at suse dot de>
- Subject: Re: i386 fpu function rewrite
- From: Jan Hubicka <jh at suse dot cz>
- Date: Sun, 6 May 2001 00:31:54 +0200
- Cc: libc-alpha at sources dot redhat dot com, Jan Hubicka <jh at suse dot cz>
- References: <firstname.lastname@example.org>
> /* acos = atan (sqrt(1 - x^2) / x) */
> __ieee754_acos (double x)
> double res;
> asm ("fld %%st /* x : x */
> fmul %%st(0) /* x^2 : x */
> fld1 /* 1 : x^2 : x */
> fsubp /* 1 - x^2 : x */
> fsqrt /* sqrt (1 - x^2) : x */
> fxch %%st(1) /* x : sqrt (1 - x^2) */
> fpatan /* atan (sqrt(1 - x^2) / x) */"
> : "=t" (res) : "0" (x) : "st(1)");
Most of the instructions here can be generated by gcc itself.
I would say that it is preferable to use c code that calls few
macros to output instructions like fpatan and similar beasts.
This has advantage, that we can use gcc to optimize functions for given
CPU (beside scheduling there are few optimizations gcc can do, like
replacing fld1 by memory load on Pentium) and in future we would like to
replace macros by intrics, like SSE support have.
On the other hand, the reload pass may bring unnecesary fxch instructions
even in such trivial code streams, so I am not sure this is really good
idea, given that gcc will probably stay weak forever on this side.
> return res;
> This assembles to the same file if I use -momit-leaf-frame-pointer or
> -fomit-frame-pointer, otherwise the frame pointer is added.
> I can also easily use this file for x86-64. Is it ok to continue this
> way? I'd like to send in patches for glibc for e_atan and other
> functions soon.
> Andreas Jaeger
> SuSE Labs email@example.com
> private firstname.lastname@example.org