On Tue, 2023-08-15 at 20:03 +0000, Joseph Myers wrote:
> On Tue, 15 Aug 2023, chenxiaolong wrote:
>
> > In the implementation process, the "q" suffix function is
> > Re-register and associate the "__float128" type with the
> > "long double" type so that the compiler can handle the
> > corresponding function correctly. The functions implemented
> > include __builtin_{huge_valq infq, fabsq, copysignq, nanq,nansq}.
> > On the LoongArch architecture, __builtin_{fabsq,copysignq} can
> > be implemented with the instruction "bstrins.d", so that its
> > optimization effect reaches the optimal value.
>
> Why? If long double has binary128 format, you shouldn't need any of these
> functions at all; if it doesn't, just the C23 _Float128 type name and f128
> constant suffix, and associated built-in functions defined in
> builtins.def, should suffice (and since we now have _FloatN support for
> C++, C++ no longer provides a reason for adding __float128 either).
> __float128 is a legacy type name and feature and shouldn't be needed on
> any new architectures, which can just use the standard type name from the
> start.
For _Float128 GCC already does the correct thing:
_Float128 g(_Float128 x) { return __builtin_fabsf128(x); }
compiled to (with -O2):
g:
.LFB3 = .
.cfi_startproc
bstrpick.d $r5,$r5,62,0
jr $r1
.cfi_endproc
So I guess we just need
builtin_define ("__builtin_fabsq=__builtin_fabsf128");
builtin_define ("__builtin_nanq=__builtin_nanf128");
etc. to map the "q" builtins to "f128" builtins if we really need the
"q" builtins.
Joseph: the problem here is many customers of LoongArch CPUs wish to
compile their old code with minimal change. Is it acceptable to add
these builtin_define's like rs6000-c.cc? Note "a new architecture" does
not mean we'll only compile post-C2x-era programs onto it.
--
Xi Ruoyao <xry...@xry111.site>
School of Aerospace Science and Technology, Xidian University
