llvm dev - Mar 2015 - [LLVMdev] compiler-rt: AArch64 and IEEE quad-precision floating point

As part of the FreeBSD/arm64 porting effort we've been looking into
the state of compiler-rt support for quad precision long double
builtins.

I see that a decently large set of these functions exist, but AFAICT
there is no CMake or Makefile infrastructure in the tree to build
them. Are these being used by various projects' out-of-tree build
infrastructure at present, or am I just missing something?

The FreeBSD base system "buildworld" currently fails due to three
missing functions:
__floatditf
__floatunditf
__multc3

The first two look like they'd be fairly straightforward to implement.
I wonder though if it's feasible to rework the
float{,un}{s,d,t}i{s,d,x,t}f functions to share a common
implementation _impl.inc file as was done in r231965 for the other
(float->int) direction.
Of the 24 conversions compiler-rt currently lacks 6: floatditf,
floatsixf, floattitf, and the unsigned equivalents.

mul{s,d,x,t}c3 could also all share a common implementation file, and
it seems multc3 can be identical to mulxc3. I have a WIP patch
implementing that change, but would like to better understand the
background and thoughts on the approach first.

On 29 March 2015 at 22:49, Ed Maste <emaste at freebsd.org>
wrote:
> As part of the FreeBSD/arm64 porting effort we've been looking into
> the state of compiler-rt support for quad precision long double
> builtins.
>
> I see that a decently large set of these functions exist, but AFAICT
> there is no CMake or Makefile infrastructure in the tree to build
> them. Are these being used by various projects' out-of-tree build
> infrastructure at present, or am I just missing something?
Joerg, have you been using the 128-bit long double quad precision fp
routines on NetBSD AArch64?
> The FreeBSD base system "buildworld" currently fails due to three
> missing functions:
> __floatditf
> __floatunditf
> __multc3
> ...
> mul{s,d,x,t}c3 could also all share a common implementation file, and
> it seems multc3 can be identical to mulxc3. I have a WIP patch
> implementing that change, but would like to better understand the
> background and thoughts on the approach first.
I've added naive implementations of these to the compiler-rt copy in
FreeBSD (r281221 and r281223) for now for our arm64/AArch64 port.
They're trivial modifications of existing functions.

I'm still interested in pursuing a change to refactor these into a
shared implementation file included by the various .c files, but want
to have a better understanding of how (and where) these files are
currently being used.