Thanks for the tip! Similar functions (e.g. __builtin_fabsf128
(_Float128 a) are already supported by the compiler and can be handled
correctly, but functions that can be implemented on the LoongArch
architecture directly using the "bstrins" directive (e.g. fabsq,
copysignq, etc.) are better optimized because they generate fewer
assembly instructions. copysignq, etc.) on the LoongArch architecture
are better optimized because they generate fewer assembly instructions.

Translated with www.DeepL.com/Translator (free version)

在 2023-08-15二的 20:03 +0000,Joseph Myers写道:
> 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.
> 

Reply via email to