Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
在 2023-08-18五的 15:19 +0800，Xi Ruoyao写道：
> On Fri, 2023-08-18 at 15:05 +0800, Xi Ruoyao via Gcc-patches wrote:
> > On Fri, 2023-08-18 at 14:58 +0800, Xi Ruoyao via Gcc-patches wrote:
> > > On Fri, 2023-08-18 at 14:39 +0800, chenxiaolong wrote:
> > > > 在 2023-08-17四的 15:08 +，Joseph Myers写道：
> > > > > On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> > > > >
> > > > > > 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.
> > > > >
> > > > > The powerpc support for __float128 started in GCC 6,
> > > > > predating the
> > > > > support
> > > > > for _FloatN type names, built-in functions etc. in GCC 7 -
> > > > > that's
> > > > > why
> > > > > there's such backwards compatibility support there. That
> > > > > name only
> > > > > exists
> > > > > on a few architectures.
> > > > >
> > > > > If people really want to compile code using the old
> > > > > __float128 names
> > > > > for
> > > > > LoongArch I suppose you could have such #defines, but it
> > > > > would be
> > > > > better
> > > > > for people to make their code use the standard names (as
> > > > > supported
> > > > > from
> > > > > GCC 7 onwards, though only from GCC 13 in C++) and then put
> > > > > backwards
> > > > > compatibility in their code for using the __float128 names if
> > > > > they
> > > > > want to
> > > > > support the type with older GCC (GCC 6 or before for C; GCC
> > > > > 12 or
> > > > > before
> > > > > for C++) on x86_64 / i386 / powerpc / ia64. Such backwards
> > > > > compatibility
> > > > > in user code is more likely to be relevant for C++ than for
> > > > > C, given
> > > > > how
> > > > > the C++ support was added to GCC much more recently. (Note:
> > > > > I
> > > > > haven't
> > > > > checked when other compilers added support for the _Float128
> > > > > name or
> > > > > associated built-in functions, whether for C or for C++,
> > > > > which might
> > > > > also
> > > > > affect when user code wants such compatibility.)
> > > > >
> > > > Thank you for your valuable comments. On the LoongArch
> > > > architecture,
> > > > the "__float128" type is associated with float128_type_node and
> > > > the "q"
> > > > suffix function is mapped to the "f128" function. This allows
> > > > compatibility with both "__float128" and "_Float128" types in
> > > > the GCC
> > > > compiler. The new code is modified as follows:
> > > > Add the following to the loongarch-builtins.c file:
> > > > +lang_hooks.types.register_builtin_type (float128_type_node,
> > > > "__float128");
> > > > Add the following to the loongarch-c.c file:
> > > > +builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> > > > +builtin_define ("__builtin_copysignq=__builtin_copysignf128");
> > > > +builtin_define ("__builtin_nanq=__builtin_nanf128");
> > > > +builtin_define ("__builtin_nansq=__builtin_nansf128");
> > > > +builtin_define ("__builtin_infq=__builtin_inff128");
> > > > +builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
> > > >
> > > > The regression tests of the six functions were added without
> > > > problems.
> > > > However, the implementation of the __builtin_nansq() function
> > > > does not
> > > > get the result we want. The questions are as follows:
> > > > x86_64:
> > > > _Float128 ret=__builtin_nansf128("NAN");
> > > >
> > > > compiled to (with gcc test.c -O2 ):
> > > > .cfi_offset 1, -8
> > > > bl %plt(__builtin_nansf128)
> > > > ..
> > > > LoongArch:
> > > > _Float128 ret=__builtin_nansf128("NAN");
> > > > compiled to (with gcc test.c -O2 ):
> > > > .cfi_offset 1, -8
> > > > bl %plt(__builtin_nansf128)
> > >
> > > It seems wrong. It should be "bl %plt(nansf128)" instead,
> > > without the
> > > __builtin_ prefix so the implementation in libm (from Glibc) will
> > > be
> > > used instead. AFAIK __builtin_nan and __builtin_nans are rarely
> > > called
> > > with a non-empty tagp so it's not worthy to inline the
> > > implementation
> > > for non-empty tagp here.
> > >
> > > The same issue happens on x86_64:
> > >
> > > call__builtin_nansf128@PLT
> > >
> > > __builtin_nanf128 compiles correct:
> > >
> > > callnanf128@PLT
> > >
> > > I'll see if there is a ticket in https://gcc.gnu.org/bugzilla.
> > > If not
> > > I'll create one.
>
>
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
On Fri, 2023-08-18 at 15:05 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2023-08-18 at 14:58 +0800, Xi Ruoyao via Gcc-patches wrote:
> > On Fri, 2023-08-18 at 14:39 +0800, chenxiaolong wrote:
> > > 在 2023-08-17四的 15:08 +，Joseph Myers写道：
> > > > On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> > > >
> > > > > 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.
> > > >
> > > > The powerpc support for __float128 started in GCC 6, predating the
> > > > support
> > > > for _FloatN type names, built-in functions etc. in GCC 7 - that's
> > > > why
> > > > there's such backwards compatibility support there. That name only
> > > > exists
> > > > on a few architectures.
> > > >
> > > > If people really want to compile code using the old __float128 names
> > > > for
> > > > LoongArch I suppose you could have such #defines, but it would be
> > > > better
> > > > for people to make their code use the standard names (as supported
> > > > from
> > > > GCC 7 onwards, though only from GCC 13 in C++) and then put
> > > > backwards
> > > > compatibility in their code for using the __float128 names if they
> > > > want to
> > > > support the type with older GCC (GCC 6 or before for C; GCC 12 or
> > > > before
> > > > for C++) on x86_64 / i386 / powerpc / ia64. Such backwards
> > > > compatibility
> > > > in user code is more likely to be relevant for C++ than for C, given
> > > > how
> > > > the C++ support was added to GCC much more recently. (Note: I
> > > > haven't
> > > > checked when other compilers added support for the _Float128 name or
> > > > associated built-in functions, whether for C or for C++, which might
> > > > also
> > > > affect when user code wants such compatibility.)
> > > >
> > > Thank you for your valuable comments. On the LoongArch architecture,
> > > the "__float128" type is associated with float128_type_node and the "q"
> > > suffix function is mapped to the "f128" function. This allows
> > > compatibility with both "__float128" and "_Float128" types in the GCC
> > > compiler. The new code is modified as follows:
> > > Add the following to the loongarch-builtins.c file:
> > > +lang_hooks.types.register_builtin_type (float128_type_node,
> > > "__float128");
> > > Add the following to the loongarch-c.c file:
> > > +builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> > > +builtin_define ("__builtin_copysignq=__builtin_copysignf128");
> > > +builtin_define ("__builtin_nanq=__builtin_nanf128");
> > > +builtin_define ("__builtin_nansq=__builtin_nansf128");
> > > +builtin_define ("__builtin_infq=__builtin_inff128");
> > > +builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
> > >
> > > The regression tests of the six functions were added without problems.
> > > However, the implementation of the __builtin_nansq() function does not
> > > get the result we want. The questions are as follows:
> > > x86_64:
> > > _Float128 ret=__builtin_nansf128("NAN");
> > >
> > > compiled to (with gcc test.c -O2 ):
> > > .cfi_offset 1, -8
> > > bl %plt(__builtin_nansf128)
> > > ..
> > > LoongArch:
> > > _Float128 ret=__builtin_nansf128("NAN");
> > > compiled to (with gcc test.c -O2 ):
> > > .cfi_offset 1, -8
> > > bl %plt(__builtin_nansf128)
> >
> > It seems wrong. It should be "bl %plt(nansf128)" instead, without the
> > __builtin_ prefix so the implementation in libm (from Glibc) will be
> > used instead. AFAIK __builtin_nan and __builtin_nans are rarely called
> > with a non-empty tagp so it's not worthy to inline the implementation
> > for non-empty tagp here.
> >
> > The same issue happens on x86_64:
> >
> > call __builtin_nansf128@PLT
> >
> > __builtin_nanf128 compiles correct:
> >
> > call nanf128@PLT
> >
> > I'll see if there is a ticket in https://gcc.gnu.org/bugzilla. If not
> > I'll create one.
https://gcc.gnu.org/PR111058
> Alright, Glibc does not have a "nansf128" function yet. Actually there
> is even no "nans" function for the plain double type. So even a plain
> __builtin_nans("114") won't work too.
>
> If we'll fix this, we need to do it in a generic, target-independent way
> (i. e. fix it all at once for all targets).
>
> So for now, and for LoongArch specific code, the proper thing to do is
> aliasing float128_type_node as __float128 and the six
> __builtin_define's.
>
>
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
On Fri, 2023-08-18 at 14:58 +0800, Xi Ruoyao via Gcc-patches wrote:
> On Fri, 2023-08-18 at 14:39 +0800, chenxiaolong wrote:
> > 在 2023-08-17四的 15:08 +，Joseph Myers写道：
> > > On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> > >
> > > > 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.
> > >
> > > The powerpc support for __float128 started in GCC 6, predating the
> > > support
> > > for _FloatN type names, built-in functions etc. in GCC 7 - that's
> > > why
> > > there's such backwards compatibility support there. That name only
> > > exists
> > > on a few architectures.
> > >
> > > If people really want to compile code using the old __float128 names
> > > for
> > > LoongArch I suppose you could have such #defines, but it would be
> > > better
> > > for people to make their code use the standard names (as supported
> > > from
> > > GCC 7 onwards, though only from GCC 13 in C++) and then put
> > > backwards
> > > compatibility in their code for using the __float128 names if they
> > > want to
> > > support the type with older GCC (GCC 6 or before for C; GCC 12 or
> > > before
> > > for C++) on x86_64 / i386 / powerpc / ia64. Such backwards
> > > compatibility
> > > in user code is more likely to be relevant for C++ than for C, given
> > > how
> > > the C++ support was added to GCC much more recently. (Note: I
> > > haven't
> > > checked when other compilers added support for the _Float128 name or
> > > associated built-in functions, whether for C or for C++, which might
> > > also
> > > affect when user code wants such compatibility.)
> > >
> > Thank you for your valuable comments. On the LoongArch architecture,
> > the "__float128" type is associated with float128_type_node and the "q"
> > suffix function is mapped to the "f128" function. This allows
> > compatibility with both "__float128" and "_Float128" types in the GCC
> > compiler. The new code is modified as follows:
> > Add the following to the loongarch-builtins.c file:
> > +lang_hooks.types.register_builtin_type (float128_type_node,
> > "__float128");
> > Add the following to the loongarch-c.c file:
> > +builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> > +builtin_define ("__builtin_copysignq=__builtin_copysignf128");
> > +builtin_define ("__builtin_nanq=__builtin_nanf128");
> > +builtin_define ("__builtin_nansq=__builtin_nansf128");
> > +builtin_define ("__builtin_infq=__builtin_inff128");
> > +builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
> >
> > The regression tests of the six functions were added without problems.
> > However, the implementation of the __builtin_nansq() function does not
> > get the result we want. The questions are as follows:
> > x86_64:
> > _Float128 ret=__builtin_nansf128("NAN");
> >
> > compiled to (with gcc test.c -O2 ):
> > .cfi_offset 1, -8
> > bl %plt(__builtin_nansf128)
> > ..
> > LoongArch:
> > _Float128 ret=__builtin_nansf128("NAN");
> > compiled to (with gcc test.c -O2 ):
> > .cfi_offset 1, -8
> > bl %plt(__builtin_nansf128)
>
> It seems wrong. It should be "bl %plt(nansf128)" instead, without the
> __builtin_ prefix so the implementation in libm (from Glibc) will be
> used instead. AFAIK __builtin_nan and __builtin_nans are rarely called
> with a non-empty tagp so it's not worthy to inline the implementation
> for non-empty tagp here.
>
> The same issue happens on x86_64:
>
> call __builtin_nansf128@PLT
>
> __builtin_nanf128 compiles correct:
>
> call nanf128@PLT
>
> I'll see if there is a ticket in https://gcc.gnu.org/bugzilla. If not
> I'll create one.
Alright, Glibc does not have a "nansf128" function yet. Actually there
is even no "nans" function for the plain double type. So even a plain
__builtin_nans("114") won't work too.
If we'll fix this, we need to do it in a generic, target-independent way
(i. e. fix it all at once for all targets).
So for now, and for LoongArch specific code, the proper thing to do is
aliasing float128_type_node as __float128 and the six
__builtin_define's.
Please commit them to trunk if regression test passes. You need to also
add LoongArch as a target supporting __float128 in extend.texi.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
On Fri, 2023-08-18 at 14:39 +0800, chenxiaolong wrote:
> 在 2023-08-17四的 15:08 +，Joseph Myers写道：
> > On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> >
> > > 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.
> >
> > The powerpc support for __float128 started in GCC 6, predating the
> > support
> > for _FloatN type names, built-in functions etc. in GCC 7 - that's
> > why
> > there's such backwards compatibility support there. That name only
> > exists
> > on a few architectures.
> >
> > If people really want to compile code using the old __float128 names
> > for
> > LoongArch I suppose you could have such #defines, but it would be
> > better
> > for people to make their code use the standard names (as supported
> > from
> > GCC 7 onwards, though only from GCC 13 in C++) and then put
> > backwards
> > compatibility in their code for using the __float128 names if they
> > want to
> > support the type with older GCC (GCC 6 or before for C; GCC 12 or
> > before
> > for C++) on x86_64 / i386 / powerpc / ia64. Such backwards
> > compatibility
> > in user code is more likely to be relevant for C++ than for C, given
> > how
> > the C++ support was added to GCC much more recently. (Note: I
> > haven't
> > checked when other compilers added support for the _Float128 name or
> > associated built-in functions, whether for C or for C++, which might
> > also
> > affect when user code wants such compatibility.)
> >
> Thank you for your valuable comments. On the LoongArch architecture,
> the "__float128" type is associated with float128_type_node and the "q"
> suffix function is mapped to the "f128" function. This allows
> compatibility with both "__float128" and "_Float128" types in the GCC
> compiler. The new code is modified as follows:
> Add the following to the loongarch-builtins.c file:
> +lang_hooks.types.register_builtin_type (float128_type_node,
> "__float128");
> Add the following to the loongarch-c.c file:
> +builtin_define ("__builtin_fabsq=__builtin_fabsf128");
> +builtin_define ("__builtin_copysignq=__builtin_copysignf128");
> +builtin_define ("__builtin_nanq=__builtin_nanf128");
> +builtin_define ("__builtin_nansq=__builtin_nansf128");
> +builtin_define ("__builtin_infq=__builtin_inff128");
> +builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
>
> The regression tests of the six functions were added without problems.
> However, the implementation of the __builtin_nansq() function does not
> get the result we want. The questions are as follows:
> x86_64:
> _Float128 ret=__builtin_nansf128("NAN");
>
> compiled to (with gcc test.c -O2 ):
> .cfi_offset 1, -8
> bl %plt(__builtin_nansf128)
> ..
> LoongArch:
> _Float128 ret=__builtin_nansf128("NAN");
> compiled to (with gcc test.c -O2 ):
> .cfi_offset 1, -8
> bl %plt(__builtin_nansf128)
It seems wrong. It should be "bl %plt(nansf128)" instead, without the
__builtin_ prefix so the implementation in libm (from Glibc) will be
used instead. AFAIK __builtin_nan and __builtin_nans are rarely called
with a non-empty tagp so it's not worthy to inline the implementation
for non-empty tagp here.
The same issue happens on x86_64:
call__builtin_nansf128@PLT
__builtin_nanf128 compiles correct:
callnanf128@PLT
I'll see if there is a ticket in https://gcc.gnu.org/bugzilla. If not
I'll create one.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
在 2023-08-17四的 15:08 +，Joseph Myers写道：
> On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
>
> > 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.
>
> The powerpc support for __float128 started in GCC 6, predating the
> support
> for _FloatN type names, built-in functions etc. in GCC 7 - that's
> why
> there's such backwards compatibility support there. That name only
> exists
> on a few architectures.
>
> If people really want to compile code using the old __float128 names
> for
> LoongArch I suppose you could have such #defines, but it would be
> better
> for people to make their code use the standard names (as supported
> from
> GCC 7 onwards, though only from GCC 13 in C++) and then put
> backwards
> compatibility in their code for using the __float128 names if they
> want to
> support the type with older GCC (GCC 6 or before for C; GCC 12 or
> before
> for C++) on x86_64 / i386 / powerpc / ia64. Such backwards
> compatibility
> in user code is more likely to be relevant for C++ than for C, given
> how
> the C++ support was added to GCC much more recently. (Note: I
> haven't
> checked when other compilers added support for the _Float128 name or
> associated built-in functions, whether for C or for C++, which might
> also
> affect when user code wants such compatibility.)
>
Thank you for your valuable comments. On the LoongArch architecture,
the "__float128" type is associated with float128_type_node and the "q"
suffix function is mapped to the "f128" function. This allows
compatibility with both "__float128" and "_Float128" types in the GCC
compiler. The new code is modified as follows:
Add the following to the loongarch-builtins.c file:
+lang_hooks.types.register_builtin_type (float128_type_node,
"__float128");
Add the following to the loongarch-c.c file:
+builtin_define ("__builtin_fabsq=__builtin_fabsf128");
+builtin_define ("__builtin_copysignq=__builtin_copysignf128");
+builtin_define ("__builtin_nanq=__builtin_nanf128");
+builtin_define ("__builtin_nansq=__builtin_nansf128");
+builtin_define ("__builtin_infq=__builtin_inff128");
+builtin_define ("__builtin_huge_valq=__builtin_huge_valf128");
The regression tests of the six functions were added without problems.
However, the implementation of the __builtin_nansq() function does not
get the result we want. The questions are as follows:
x86_64:
_Float128 ret=__builtin_nansf128("NAN");
compiled to (with gcc test.c -O2 ):
.cfi_offset 1, -8
bl %plt(__builtin_nansf128)
..
LoongArch:
_Float128 ret=__builtin_nansf128("NAN");
compiled to (with gcc test.c -O2 ):
.cfi_offset 1, -8
bl %plt(__builtin_nansf128)
..
Obviously, there may have been legacy issues with the implementation
when "_Float128 __builtin_nansf128()" was first supported.
Architectures including LoongArch, x86_64, arm, etc. are no longer
supported, and some of the remaining architectures are unproven.
I will continue to follow up the implementation of the builtin
function and complete the function.
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
On Thu, 17 Aug 2023, Xi Ruoyao via Gcc-patches wrote:
> 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.
The powerpc support for __float128 started in GCC 6, predating the support
for _FloatN type names, built-in functions etc. in GCC 7 - that's why
there's such backwards compatibility support there. That name only exists
on a few architectures.
If people really want to compile code using the old __float128 names for
LoongArch I suppose you could have such #defines, but it would be better
for people to make their code use the standard names (as supported from
GCC 7 onwards, though only from GCC 13 in C++) and then put backwards
compatibility in their code for using the __float128 names if they want to
support the type with older GCC (GCC 6 or before for C; GCC 12 or before
for C++) on x86_64 / i386 / powerpc / ia64. Such backwards compatibility
in user code is more likely to be relevant for C++ than for C, given how
the C++ support was added to GCC much more recently. (Note: I haven't
checked when other compilers added support for the _Float128 name or
associated built-in functions, whether for C or for C++, which might also
affect when user code wants such compatibility.)
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
Okay, thanks for the heads up! I'll try to format the code according to
the GNU Coding Standards. I'll double-check every line of the submitted
patch to make sure that I don't have such a low-level formatting
problem in every future patch, so that I can comply with the code
specification.
在 2023-08-15二的 18:48 +0800，Xi Ruoyao写道：
> Please fix code style (this is the third time I say it and I'm really
> frustrated now). GCC is a project, it's not a student homework so
> style
> matters. And it's not so difficult to fix the style: for a new file
> you
> can use "clang-format --style GNU -i filename.c" to do the work
> automatically.
>
> On Tue, 2023-08-15 at 18:39 +0800, 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.
> >
> > gcc/ChangeLog:
> >
> > * config/loongarch/loongarch-builtins.cc (DEF_LARCH_FTYPE):
> > (enum loongarch_builtin_type):Increases the type of the
> > function.
> > (FLOAT_BUILTIN_HIQ):__builtin_{huge_valq,infq}.
> > (FLOAT_BUILTIN_FCQ):__builtin_{fabsq,copysignq}.
> > (FLOAT_BUILTIN_NNQ):__builtin_{nanq,nansq}.
> > (loongarch_init_builtins):
> > (loongarch_fold_builtin):
> > (loongarch_expand_builtin):
> > * config/loongarch/loongarch-protos.h
> > (loongarch_fold_builtin):
> > (loongarch_c_mode_for_suffix):Add the declaration of the
> > function.
> > * config/loongarch/loongarch.cc
> > (loongarch_c_mode_for_suffix):Add
> > the definition of the function.
> > (TARGET_FOLD_BUILTIN):
> > (TARGET_C_MODE_FOR_SUFFIX):
> > * config/loongarch/loongarch.md (infq):Add an instruction
> > template
> > to the machine description file to generate information
> > such as
> > the icode used by the function and the constructor.
> > ():
> > (fabsq):
> > (copysignq):
> >
> > libgcc/ChangeLog:
> >
> > * config/loongarch/t-softfp-tf:
> > * config/loongarch/tf-signs.c: New file.
> > ---
> > gcc/config/loongarch/loongarch-builtins.cc | 168
> > -
> > gcc/config/loongarch/loongarch-protos.h| 2 +
> > gcc/config/loongarch/loongarch.cc | 14 ++
> > gcc/config/loongarch/loongarch.md | 69 +
> > libgcc/config/loongarch/t-softfp-tf| 3 +
> > libgcc/config/loongarch/tf-signs.c | 59
> > 6 files changed, 313 insertions(+), 2 deletions(-)
> > create mode 100644 libgcc/config/loongarch/tf-signs.c
> >
> > diff --git a/gcc/config/loongarch/loongarch-builtins.cc
> > b/gcc/config/loongarch/loongarch-builtins.cc
> > index b929f224dfa..2fb0fde0e3f 100644
> > --- a/gcc/config/loongarch/loongarch-builtins.cc
> > +++ b/gcc/config/loongarch/loongarch-builtins.cc
> > @@ -36,6 +36,8 @@ along with GCC; see the file COPYING3. If not
> > see
> > #include "fold-const.h"
> > #include "expr.h"
> > #include "langhooks.h"
> > +#include "calls.h"
> > +#include "explow.h"
> >
> > /* Macros to create an enumeration identifier for a function
> > prototype. */
> > #define LARCH_FTYPE_NAME1(A, B) LARCH_##A##_FTYPE_##B
> > @@ -48,9 +50,18 @@ enum loongarch_function_type
> > #define DEF_LARCH_FTYPE(NARGS, LIST) LARCH_FTYPE_NAME##NARGS LIST,
> > #include "config/loongarch/loongarch-ftypes.def"
> > #undef DEF_LARCH_FTYPE
> > + LARCH_BUILTIN_HUGE_VALQ,
> > + LARCH_BUILTIN_INFQ,
> > + LARCH_BUILTIN_FABSQ,
> > + LARCH_BUILTIN_COPYSIGNQ,
> > + LARCH_BUILTIN_NANQ,
> > + LARCH_BUILTIN_NANSQ,
> >LARCH_MAX_FTYPE_MAX
> > };
> >
> > +/* Count the number of functions with "q" as the suffix. */
> > +const int MATHQ_NUMS = (int)LARCH_MAX_FTYPE_MAX -
> > (int)LARCH_BUILTIN_HUGE_VALQ;
> > +
> > /* Specifies how a built-in function should be converted into
> > rtl. */
> > enum loongarch_builtin_type
> > {
> > @@ -63,6 +74,15 @@ enum loongarch_builtin_type
> > value and the arguments are mapped to operands 0 and above.
> > */
> >LARCH_BUILTIN_DIRECT_NO_TARGET,
> >
> > + /* The function corresponds to __builtin_{huge_valq,infq}. */
> > + LARCH_BUILTIN_HIQ_DIRECT,
> > +
> > + /* The function corresponds to __builtin_{fabsq,copysignq}. */
> > + LARCH_BUILTIN_FCQ_DIRECT,
> > +
> > + /* Define the type of the __builtin_{nanq,nansq} function. */
> > + LARCH_BUILTIN_NNQ_DIRECT
> > +
> > };
> >
> > /* Declare an availability predicate for built-in functions that
> > require
> > @@ -136,6 +156,24 @@ AVAIL_ALL (hard_float,
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
On Tue, 2023-08-15 at 20:03 +, 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
School of Aerospace Science and Technology, Xidian University
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
On Wed, 16 Aug 2023, chenxiaolong wrote: > 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. Then you should make the existing built-in functions for _Float128 or long double generate the desired instructions, rather than adding a legacy and duplicative API to a new architecture. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
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 +，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.
>
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
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.
--
Joseph S. Myers
jos...@codesourcery.com
Re: [PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
Please fix code style (this is the third time I say it and I'm really
frustrated now). GCC is a project, it's not a student homework so style
matters. And it's not so difficult to fix the style: for a new file you
can use "clang-format --style GNU -i filename.c" to do the work
automatically.
On Tue, 2023-08-15 at 18:39 +0800, 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.
>
> gcc/ChangeLog:
>
> * config/loongarch/loongarch-builtins.cc (DEF_LARCH_FTYPE):
> (enum loongarch_builtin_type):Increases the type of the function.
> (FLOAT_BUILTIN_HIQ):__builtin_{huge_valq,infq}.
> (FLOAT_BUILTIN_FCQ):__builtin_{fabsq,copysignq}.
> (FLOAT_BUILTIN_NNQ):__builtin_{nanq,nansq}.
> (loongarch_init_builtins):
> (loongarch_fold_builtin):
> (loongarch_expand_builtin):
> * config/loongarch/loongarch-protos.h (loongarch_fold_builtin):
> (loongarch_c_mode_for_suffix):Add the declaration of the function.
> * config/loongarch/loongarch.cc (loongarch_c_mode_for_suffix):Add
> the definition of the function.
> (TARGET_FOLD_BUILTIN):
> (TARGET_C_MODE_FOR_SUFFIX):
> * config/loongarch/loongarch.md (infq):Add an instruction template
> to the machine description file to generate information such as
> the icode used by the function and the constructor.
> ():
> (fabsq):
> (copysignq):
>
> libgcc/ChangeLog:
>
> * config/loongarch/t-softfp-tf:
> * config/loongarch/tf-signs.c: New file.
> ---
> gcc/config/loongarch/loongarch-builtins.cc | 168 -
> gcc/config/loongarch/loongarch-protos.h | 2 +
> gcc/config/loongarch/loongarch.cc | 14 ++
> gcc/config/loongarch/loongarch.md | 69 +
> libgcc/config/loongarch/t-softfp-tf | 3 +
> libgcc/config/loongarch/tf-signs.c | 59
> 6 files changed, 313 insertions(+), 2 deletions(-)
> create mode 100644 libgcc/config/loongarch/tf-signs.c
>
> diff --git a/gcc/config/loongarch/loongarch-builtins.cc
> b/gcc/config/loongarch/loongarch-builtins.cc
> index b929f224dfa..2fb0fde0e3f 100644
> --- a/gcc/config/loongarch/loongarch-builtins.cc
> +++ b/gcc/config/loongarch/loongarch-builtins.cc
> @@ -36,6 +36,8 @@ along with GCC; see the file COPYING3. If not see
> #include "fold-const.h"
> #include "expr.h"
> #include "langhooks.h"
> +#include "calls.h"
> +#include "explow.h"
>
> /* Macros to create an enumeration identifier for a function prototype. */
> #define LARCH_FTYPE_NAME1(A, B) LARCH_##A##_FTYPE_##B
> @@ -48,9 +50,18 @@ enum loongarch_function_type
> #define DEF_LARCH_FTYPE(NARGS, LIST) LARCH_FTYPE_NAME##NARGS LIST,
> #include "config/loongarch/loongarch-ftypes.def"
> #undef DEF_LARCH_FTYPE
> + LARCH_BUILTIN_HUGE_VALQ,
> + LARCH_BUILTIN_INFQ,
> + LARCH_BUILTIN_FABSQ,
> + LARCH_BUILTIN_COPYSIGNQ,
> + LARCH_BUILTIN_NANQ,
> + LARCH_BUILTIN_NANSQ,
> LARCH_MAX_FTYPE_MAX
> };
>
> +/* Count the number of functions with "q" as the suffix. */
> +const int MATHQ_NUMS = (int)LARCH_MAX_FTYPE_MAX -
> (int)LARCH_BUILTIN_HUGE_VALQ;
> +
> /* Specifies how a built-in function should be converted into rtl. */
> enum loongarch_builtin_type
> {
> @@ -63,6 +74,15 @@ enum loongarch_builtin_type
> value and the arguments are mapped to operands 0 and above. */
> LARCH_BUILTIN_DIRECT_NO_TARGET,
>
> + /* The function corresponds to __builtin_{huge_valq,infq}. */
> + LARCH_BUILTIN_HIQ_DIRECT,
> +
> + /* The function corresponds to __builtin_{fabsq,copysignq}. */
> + LARCH_BUILTIN_FCQ_DIRECT,
> +
> + /* Define the type of the __builtin_{nanq,nansq} function. */
> + LARCH_BUILTIN_NNQ_DIRECT
> +
> };
>
> /* Declare an availability predicate for built-in functions that require
> @@ -136,6 +156,24 @@ AVAIL_ALL (hard_float, TARGET_HARD_FLOAT_ABI)
> LARCH_BUILTIN (INSN, #INSN, LARCH_BUILTIN_DIRECT_NO_TARGET, \
> FUNCTION_TYPE, AVAIL)
>
> +/* Define an float to do funciton {huge_valq,infq}. */
> +#define FLOAT_BUILTIN_HIQ (INSN, FUNCTION_TYPE) \
> + { CODE_FOR_ ## INSN, \
> + "__builtin_" #INSN, LARCH_BUILTIN_HIQ_DIRECT, \
> + FUNCTION_TYPE, loongarch_builtin_avail_default }
> +
> +/* Define an float to do funciton {fabsq,copysignq}. */
> +#define FLOAT_BUILTIN_FCQ (INSN, FUNCTION_TYPE) \
> + { CODE_FOR_ ## INSN,
[PATCH v3] LoongArch:Implement 128-bit floating point functions in gcc.
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.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc (DEF_LARCH_FTYPE):
(enum loongarch_builtin_type):Increases the type of the function.
(FLOAT_BUILTIN_HIQ):__builtin_{huge_valq,infq}.
(FLOAT_BUILTIN_FCQ):__builtin_{fabsq,copysignq}.
(FLOAT_BUILTIN_NNQ):__builtin_{nanq,nansq}.
(loongarch_init_builtins):
(loongarch_fold_builtin):
(loongarch_expand_builtin):
* config/loongarch/loongarch-protos.h (loongarch_fold_builtin):
(loongarch_c_mode_for_suffix):Add the declaration of the function.
* config/loongarch/loongarch.cc (loongarch_c_mode_for_suffix):Add
the definition of the function.
(TARGET_FOLD_BUILTIN):
(TARGET_C_MODE_FOR_SUFFIX):
* config/loongarch/loongarch.md (infq):Add an instruction template
to the machine description file to generate information such as
the icode used by the function and the constructor.
():
(fabsq):
(copysignq):
libgcc/ChangeLog:
* config/loongarch/t-softfp-tf:
* config/loongarch/tf-signs.c: New file.
---
gcc/config/loongarch/loongarch-builtins.cc | 168 -
gcc/config/loongarch/loongarch-protos.h| 2 +
gcc/config/loongarch/loongarch.cc | 14 ++
gcc/config/loongarch/loongarch.md | 69 +
libgcc/config/loongarch/t-softfp-tf| 3 +
libgcc/config/loongarch/tf-signs.c | 59
6 files changed, 313 insertions(+), 2 deletions(-)
create mode 100644 libgcc/config/loongarch/tf-signs.c
diff --git a/gcc/config/loongarch/loongarch-builtins.cc
b/gcc/config/loongarch/loongarch-builtins.cc
index b929f224dfa..2fb0fde0e3f 100644
--- a/gcc/config/loongarch/loongarch-builtins.cc
+++ b/gcc/config/loongarch/loongarch-builtins.cc
@@ -36,6 +36,8 @@ along with GCC; see the file COPYING3. If not see
#include "fold-const.h"
#include "expr.h"
#include "langhooks.h"
+#include "calls.h"
+#include "explow.h"
/* Macros to create an enumeration identifier for a function prototype. */
#define LARCH_FTYPE_NAME1(A, B) LARCH_##A##_FTYPE_##B
@@ -48,9 +50,18 @@ enum loongarch_function_type
#define DEF_LARCH_FTYPE(NARGS, LIST) LARCH_FTYPE_NAME##NARGS LIST,
#include "config/loongarch/loongarch-ftypes.def"
#undef DEF_LARCH_FTYPE
+ LARCH_BUILTIN_HUGE_VALQ,
+ LARCH_BUILTIN_INFQ,
+ LARCH_BUILTIN_FABSQ,
+ LARCH_BUILTIN_COPYSIGNQ,
+ LARCH_BUILTIN_NANQ,
+ LARCH_BUILTIN_NANSQ,
LARCH_MAX_FTYPE_MAX
};
+/* Count the number of functions with "q" as the suffix. */
+const int MATHQ_NUMS = (int)LARCH_MAX_FTYPE_MAX - (int)LARCH_BUILTIN_HUGE_VALQ;
+
/* Specifies how a built-in function should be converted into rtl. */
enum loongarch_builtin_type
{
@@ -63,6 +74,15 @@ enum loongarch_builtin_type
value and the arguments are mapped to operands 0 and above. */
LARCH_BUILTIN_DIRECT_NO_TARGET,
+ /* The function corresponds to __builtin_{huge_valq,infq}. */
+ LARCH_BUILTIN_HIQ_DIRECT,
+
+ /* The function corresponds to __builtin_{fabsq,copysignq}. */
+ LARCH_BUILTIN_FCQ_DIRECT,
+
+ /* Define the type of the __builtin_{nanq,nansq} function. */
+ LARCH_BUILTIN_NNQ_DIRECT
+
};
/* Declare an availability predicate for built-in functions that require
@@ -136,6 +156,24 @@ AVAIL_ALL (hard_float, TARGET_HARD_FLOAT_ABI)
LARCH_BUILTIN (INSN, #INSN, LARCH_BUILTIN_DIRECT_NO_TARGET, \
FUNCTION_TYPE, AVAIL)
+/* Define an float to do funciton {huge_valq,infq}. */
+#define FLOAT_BUILTIN_HIQ (INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ ## INSN, \
+"__builtin_" #INSN, LARCH_BUILTIN_HIQ_DIRECT,\
+FUNCTION_TYPE, loongarch_builtin_avail_default }
+
+/* Define an float to do funciton {fabsq,copysignq}. */
+#define FLOAT_BUILTIN_FCQ (INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ ## INSN, \
+"__builtin_" #INSN, LARCH_BUILTIN_FCQ_DIRECT,\
+FUNCTION_TYPE, loongarch_builtin_avail_default }
+
+/* Define an float to do funciton {nanq,nansq}. */
+#define FLOAT_BUILTIN_NNQ (INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ ## INSN, \
+"__builtin_" #INSN, LARCH_BUILTIN_NNQ_DIRECT, \
+FUNCTION_TYPE, loongarch_builtin_avail_default }
+
static const struct loongarch_builtin_description loongarch_builtins[] = {
#define LARCH_MOVFCSR2GR 0
DIRECT_BUILTIN (movfcsr2gr, LARCH_USI_FTYPE_UQI, hard_float),
