Hello!
A little background:
Some time ago, Richard Guenther proposed that GCC imports libm math
library from libc sources, but this proposal went nowhere, mostly due to
non-technical reasons. At the time, the idea was that having a local
math library, we could implement high-performance math library that will
use SSE instructions with x86_64-like register passing convention also
on i686-class 32bit targets. Since then, x86_64 gained soft-float 128bit
support, but there was no 128bit libm available to fully exploit the
potential of this high-precision infrastructure.
The proposal:
Forwarded is a short discussion with Mr. de Dinechin (forwarded with
permission), where the possibility to import crlibm as the default gcc
math library is discussed. I would like to ask members of the GCC SC for
the opinion on the idea of adopting crlibm as the default math library.
This way, the library can be compiled using all knowledge that gcc has
about the target processor. As hinted in the attached message -
autovectorization and perhaps recently introduced fixed-point
infrastructure can be used effectively in the implementation of this
library, as well as new AMD's FMA instructions.
The conclusion:
I think that including active maintained high-accuracy math library in
GCC would be an important step to use GCC as a high-performance compiler
in FP intensive applications.
Uros.
---forwarded message---
Hello,
We are very interested. Actually we are more and more working on
automatic generation of libm functions, as opposed to writing the
functions themselves. See
http://perso.ens-lyon.fr/christoph.lauter/intelportland.pdf
for a recent overview of what we have.
So our research direction is clearly towards compilers, not libraries.
However the development workforce is now reduced to one third-year PhD
student (Christoph) and one lecturer (myself), both of whom work
part-time on crlibm-related research. It is a small workforce for such a
wide project. Do you think there could be some way to involve more
people, or fund a post-doc or an engineer?
This was the political answer. More technical comments and issues below.
Uros Bizjak a écrit :
Hello!
GCC (GNU Compiler Collection) community is looking to include a libm
library as a part of gcc support library in future releases of gcc.
This way, we plan to introduce certain optimizations and enhancement
in FP intensive code, that can be achieved only by tightly coupling
the compiler and high-performance libm implementation.
We totally agree. For the kind of optimizations related to scheduling,
such as loop pipelining etc, we have little competence, however we are
very interested in more arithmetic optimizations, such as expression
fusing, compile-time generation of optimized polynomial approximations,
sharing argument reduction for sin and cos of the same value, etc.
Actually we would like to know what static information gcc would
currently be able to provide to a floating-point optimizer.
Some time ago, there was an offer from your side [1] to gradually
include crlibm in glibc [1]. We think, that more appropriate place for
this library could be directly in the compiler infrastructure, so all
supported targets can automatically inherit the capabilities of crlibm
(newlib and uClinux targets, for example).
Yes.
In addition to target-dependant optimizations that can be achieved by
coupling crlibm and the compiler, such as:
a) usage of target processor specific instructions (cmove, FMA) and
instruction sets (SSEn)
b) optimal scheduling of the instructions for certain processor
c) various target microoptimizations
Yes to all.
On one hand, CRLibm can be retargetted relatively easily. It already
uses macros for the FMA which accelerate it on PowerPC and IA64 for
instance, and it was written with sufficient dataparallelism to enable
SSE usage, although current gcc doesn't seem to be able to exploit it
(hint).
However it will never be efficient on targets without an FPU, for instance.
On the other hand, we are prototyping the automatic implementation of
libm functions. It is based on the Sollya tool
http://sollya.gforge.inria.fr/
Although Sollya was never intended to be included in a compiler, it can
be used to generate target-specific code. It still needs quite a lot of
development, though.
gcc currently provides the full infrastructure for soft-FP 128bit long
double values on a mainstream processor (x86_64). Current libm
implementation doesn't use this infrastructure, and there are no plans
to do so. Unfortunately, this locks out important segment of users
(fluid dynamics) that would benefit greatly from increased precision;
both from correct libm implementation and from increased bit widths.
There are two issues here. The first is using 128-bit FP to provide
64-bit FP correctly rounded elementary functions. This is possible, but
probably less efficient than the current approach in CRLibm (using
double-double and triple-double).
The second is developping a 128-bit libm, either using soft 128 bit FP,
or in an ad-hoc way (using combinations of double, double-double,
triple-double, etc, or going fixed-point, whichever proves more
efficient). Again, we favor the ad-hoc way, and Sollya can be used for
that, too. Again at the cost of some development, but this is something
that interests us.
I would like to establish "first contact" to kindly ask you what is
your opinion about including your library as a default math library
into gcc sources, before posting formal proposal to gcc@ mailing list.
I think that both, gcc and crlibm could benefit from using your
library as a default math library in gcc compiler.
We totally agree. Note that there should be no problem with copyright
transfers.
Incidentally, would there be a possibility of physically meeting
somewhere in Europe?
Florent and Christoph
[1] http://sources.redhat.com/ml/libc-alpha/2007-02/msg00007.html
Looking forward to hearing from you,
Uros.
