[PATCH v1] LoongArch: testsuite:Fix problems with incorrect results in vector test cases.
In simd_correctness_check.h, the role of the macro ASSERTEQ_64 is to check the
result of the passed vector values for the 64-bit data of each array element.
It turns out that it uses the abs() function to check only the lower 32 bits
of the data at a time, so it replaces abs() with the llabs() function.
However, the following two problems may occur after modification:
1.FAIL in lasx-xvfrint_s.c and lsx-vfrint_s.c
The reason for the error is because vector test cases that use __m{128,256} to
define vector types are composed of 32-bit primitive types, they should use
ASSERTEQ_32 instead of ASSERTEQ_64 to check for correctness.
2.FAIL in lasx-xvshuf_b.c and lsx-vshuf.c
The cause of the error is that the expected result of the function setting in
the test case is incorrect.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/lasx/lasx-xvfrint_s.c: Replace
ASSERTEQ_64 with the macro ASSERTEQ_32.
* gcc.target/loongarch/vector/lasx/lasx-xvshuf_b.c: Modify the expected
test results of some functions according to the function of the vector
instruction.
* gcc.target/loongarch/vector/lsx/lsx-vfrint_s.c: Same
modification as lasx-xvfrint_s.c.
* gcc.target/loongarch/vector/lsx/lsx-vshuf.c: Same
modification as lasx-xvshuf_b.c.
* gcc.target/loongarch/vector/simd_correctness_check.h: Use the llabs()
function instead of abs() to check the correctness of the results.
---
.../loongarch/vector/lasx/lasx-xvfrint_s.c| 58 +--
.../loongarch/vector/lasx/lasx-xvshuf_b.c | 14 ++---
.../loongarch/vector/lsx/lsx-vfrint_s.c | 50
.../loongarch/vector/lsx/lsx-vshuf.c | 12 ++--
.../loongarch/vector/simd_correctness_check.h | 2 +-
5 files changed, 68 insertions(+), 68 deletions(-)
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvfrint_s.c
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvfrint_s.c
index fbfe300eac4..4538528a67f 100644
--- a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvfrint_s.c
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvfrint_s.c
@@ -184,7 +184,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7]) = 0x;
*((int *)&__m256_op0[6]) = 0x;
@@ -203,7 +203,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7]) = 0x;
*((int *)&__m256_op0[6]) = 0x;
@@ -222,7 +222,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7]) = 0x01010101;
*((int *)&__m256_op0[6]) = 0x01010101;
@@ -241,7 +241,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7]) = 0x;
*((int *)&__m256_op0[6]) = 0x;
@@ -260,7 +260,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7]) = 0x;
*((int *)&__m256_op0[6]) = 0x;
@@ -279,7 +279,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7]) = 0x;
*((int *)&__m256_op0[6]) = 0x;
@@ -298,7 +298,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7]) = 0x01010101;
*((int *)&__m256_op0[6]) = 0x01010101;
@@ -317,7 +317,7 @@ main ()
*((int *)&__m256_result[1]) = 0x;
*((int *)&__m256_result[0]) = 0x;
__m256_out = __lasx_xvfrintrne_s (__m256_op0);
- ASSERTEQ_64 (__LINE__, __m256_result, __m256_out);
+ ASSERTEQ_32 (__LINE__, __m256_result, __m256_out);
*((int *)&__m256_op0[7])
[PATCH v3] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
gcc/testsuite/ChangeLog:
* gcc.dg/signbit-2.c: Added additional "-mlsx" compilation options.
* gfortran.dg/graphite/vect-pr40979.f90: Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
---
gcc/testsuite/gcc.dg/signbit-2.c | 1 +
gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90| 1 +
gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
3 files changed, 3 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
index 62bb4047d74..5511bb78149 100644
--- a/gcc/testsuite/gcc.dg/signbit-2.c
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -5,6 +5,7 @@
/* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-*-*
x86_64-*-* } } } */
/* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
/* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
+/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
/* { dg-skip-if "no fallback for MVE" { arm_mve } } */
#include
diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
index a42290948c4..6f2ad1166a4 100644
--- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
@@ -1,6 +1,7 @@
! { dg-do compile }
! { dg-require-effective-target vect_double }
! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-* } && ilp32
} } }
+! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
module mqc_m
integer, parameter, private :: longreal = selected_real_kind(15,90)
diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
index 08965cc5e20..97b88821731 100644
--- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
+++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
@@ -2,6 +2,7 @@
! { dg-require-effective-target vect_double }
! { dg-options "-O3 --param vect-max-peeling-for-alignment=0
-fpredictive-commoning -fdump-tree-pcom-details -std=legacy" }
! { dg-additional-options "-mprefer-avx128" { target { i?86-*-* x86_64-*-* } }
}
+! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
*** RESID COMPUTES THE RESIDUAL: R = V - AU
--
2.20.1
Re: [PATCH] testsuite: Make pr104992.c irrelated to target vector feature [PR113418]
At 19:00 +0800 on Wednesday, 2024-01-24, Xi Ruoyao wrote：
> On Wed, 2024-01-24 at 18:32 +0800, chenxiaolong wrote:
> > On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote：
> > > The vect_int_mod target selector is evaluated with the options in
> > > DEFAULT_VECTCFLAGS in effect, but these options are not
> > > automatically
> > > passed to tests out of the vect directories. So this test fails
> > > on
> > > targets where integer vector modulo operation is supported but
> > > requiring
> > > an option to enable, for example LoongArch.
> > >
> > > In this test case, the only expected optimization not happened in
> > > original is in corge because it needs forward propogation. So we
> > > can
> > > scan the forwprop2 dump (where the vector operation is not
> > > expanded
> > > to
> > > scalars yet) instead of optimized, then we don't need to consider
> > > vect_int_mod or not.
> > >
> > > gcc/testsuite/ChangeLog:
> > >
> > > PR testsuite/113418
> > > * gcc.dg/pr104992.c (dg-options): Use -fdump-tree-forwprop2
> > > instead of -fdump-tree-optimized.
> > > (dg-final): Scan forwprop2 dump instead of optimized, and
> > > remove
> > > the use of vect_int_mod.
> > > ---
> > >
> > > This fixes the test failure on loongarch64-linux-gnu, and I've
> > > also
> > > tested it on x86_64-linux-gnu. Ok for trunk?
> > >
> > > gcc/testsuite/gcc.dg/pr104992.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/gcc/testsuite/gcc.dg/pr104992.c
> > > b/gcc/testsuite/gcc.dg/pr104992.c
> > > index 82f8c75559c..6fd513d34b2 100644
> > > --- a/gcc/testsuite/gcc.dg/pr104992.c
> > > +++ b/gcc/testsuite/gcc.dg/pr104992.c
> > > @@ -1,6 +1,6 @@
> > > /* PR tree-optimization/104992 */
> > > /* { dg-do compile } */
> > > -/* { dg-options "-O2 -Wno-psabi -fdump-tree-optimized" } */
> > > +/* { dg-options "-O2 -Wno-psabi -fdump-tree-forwprop2" } */
> > >
> > > #define vector __attribute__((vector_size(4*sizeof(int
> > >
> > > @@ -54,5 +54,4 @@ __attribute__((noipa)) unsigned waldo (unsigned
> > > x,
> > > unsigned y, unsigned z) {
> > > return x / y * z == x;
> > > }
> > >
> > > -/* { dg-final { scan-tree-dump-times " % " 9 "optimized" {
> > > target {
> > > ! vect_int_mod } } } } */
> > > -/* { dg-final { scan-tree-dump-times " % " 6 "optimized" {
> > > target
> > > vect_int_mod } } } */
> > > +/* { dg-final { scan-tree-dump-times " % " 6 "forwprop2" } } */
> >
> > Hello, currently vect_int_mod vectorization operation detection
> > only
> > ppc,amd,riscv,LoongArch architecture support. When -fdump-tree-
> > forwprop2 is used instead of -fdump-tree-optimized, The
> > check_effective_target_vect_int_mod procedure defined in the
> > target-
> > supports.exp file will never be called. It will only be called on
> > pr104992.c, should we consider supporting other architectures?
>
> Hmm, then we should remove check_effective_target_vect_int_mod.
>
> If we want to keep -fdump-tree-optimized for this test case and also
> make it correct, we'll at least have to move it into vect/, and write
> something like
>
> { dg-final { scan-tree-dump-times " % " 9 "optimized" { target { !
> vect_int_mod } } } }
> { dg-final { scan-tree-dump-times " % " 6 "optimized" { target {
> vect_int_mod && vect128 } } } }
> { dg-final { scan-tree-dump-times " % " 7 "optimized" { target {
> vect_int_mod && vect64 && !vect128 } } } }
>
> and how about vect256 etc? This would be very nasty and deviating
> from
> the original purpose of this test case (against PR104992, which is a
> missed-optimization issue unrelated to vectors).
>
Ok, let me think about how to make the pr104992.c test case more
reasonable.
Re: [PATCH] testsuite: Make pr104992.c irrelated to target vector feature [PR113418]
On 20:09 +0800 on Tuesday, 2024-01-23, Xi Ruoyao wrote：
> The vect_int_mod target selector is evaluated with the options in
> DEFAULT_VECTCFLAGS in effect, but these options are not automatically
> passed to tests out of the vect directories. So this test fails on
> targets where integer vector modulo operation is supported but
> requiring
> an option to enable, for example LoongArch.
>
> In this test case, the only expected optimization not happened in
> original is in corge because it needs forward propogation. So we can
> scan the forwprop2 dump (where the vector operation is not expanded
> to
> scalars yet) instead of optimized, then we don't need to consider
> vect_int_mod or not.
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/113418
> * gcc.dg/pr104992.c (dg-options): Use -fdump-tree-forwprop2
> instead of -fdump-tree-optimized.
> (dg-final): Scan forwprop2 dump instead of optimized, and
> remove
> the use of vect_int_mod.
> ---
>
> This fixes the test failure on loongarch64-linux-gnu, and I've also
> tested it on x86_64-linux-gnu. Ok for trunk?
>
> gcc/testsuite/gcc.dg/pr104992.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/testsuite/gcc.dg/pr104992.c
> b/gcc/testsuite/gcc.dg/pr104992.c
> index 82f8c75559c..6fd513d34b2 100644
> --- a/gcc/testsuite/gcc.dg/pr104992.c
> +++ b/gcc/testsuite/gcc.dg/pr104992.c
> @@ -1,6 +1,6 @@
> /* PR tree-optimization/104992 */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -Wno-psabi -fdump-tree-optimized" } */
> +/* { dg-options "-O2 -Wno-psabi -fdump-tree-forwprop2" } */
>
> #define vector __attribute__((vector_size(4*sizeof(int
>
> @@ -54,5 +54,4 @@ __attribute__((noipa)) unsigned waldo (unsigned x,
> unsigned y, unsigned z) {
> return x / y * z == x;
> }
>
> -/* { dg-final { scan-tree-dump-times " % " 9 "optimized" { target {
> ! vect_int_mod } } } } */
> -/* { dg-final { scan-tree-dump-times " % " 6 "optimized" { target
> vect_int_mod } } } */
> +/* { dg-final { scan-tree-dump-times " % " 6 "forwprop2" } } */
Hello, currently vect_int_mod vectorization operation detection only
ppc,amd,riscv,LoongArch architecture support. When -fdump-tree-
forwprop2 is used instead of -fdump-tree-optimized, The
check_effective_target_vect_int_mod procedure defined in the target-
supports.exp file will never be called. It will only be called on
pr104992.c, should we consider supporting other architectures?
[PATCH v1] LoongArch: doc:Combined with the content of target-supports.exp, add the attribute description related to LoongArch.
gcc/ChangeLog: * doc/sourcebuild.texi: Add attributes for keywords. --- gcc/doc/sourcebuild.texi | 20 1 file changed, 20 insertions(+) diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi index 8082100a3c9..6c33237ac78 100644 --- a/gcc/doc/sourcebuild.texi +++ b/gcc/doc/sourcebuild.texi @@ -2352,6 +2352,26 @@ AArch64 target that is able to generate and execute armv8.3-a FJCVTZS instruction. @end table +@subsubsection LoongArch specific attributes + +@table @code +@item loongarch_sx +LoongArch target that generates instructions for SX. + +@item loongarch_asx +LoongArch target that generates instructions for ASX. + +@item loongarch_sx_hw +LoongArch target that is able to generate and execute SX code. + +@item loongarch_asx_hw +LoongArch target that is able to generate and execute ASX code. + +@item loongarch_call36_support +LoongArch binutils supports call36 relocation. + +@end table + @subsubsection MIPS-specific attributes @table @code -- 2.20.1
Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道： > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote: > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote： > > > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote: > > > > Xi Ruoyao wrote at 12:11pm on Monday, > > > > January > > > > 15, 2024： > > > > > On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote: > > > > > > At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote： > > > > > > > At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong > > > > > > > wrote： > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > > > > > > >* gcc.dg/pr104992.c: Added additional "-mlsx" > > > > > > > > compilation > > > > > > > > options. > > > > > > > >* gcc.dg/signbit-2.c: Dito. > > > > > > > >* gcc.dg/tree-ssa/scev-16.c: Dito. > > > > > > > >* gfortran.dg/graphite/vect-pr40979.f90: Dito. > > > > > > > >* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito. > > > > > > > > > > > > > > I don't feel it right about the changes to pr104992.c and > > > > > > > scev-16.c > > > > > > > because no other architectures add special options > > > > > > > there. > > > > > > > Why are we > > > > > > > so special? > > > > > > Because on the LoongArch architecture, GCC requires the > > > > > > addition of > > > > > > vectorization options in order to generate vector code. Use > > > > > > the > > > > > > check_effective_target_vect_cmdline_needed command in the > > > > > > lib/target- > > > > > > supports.exp file to set whether the command line option is > > > > > > needed to > > > > > > enable vectorizations. For example, ia64,x86,aarch64, and > > > > > > riscv > > > > > > architectures, vectorization is enabled by default. > > > > > > > > > > But no. The default baseline of 32-bit x86 is i686, which is > > > > > basically > > > > > a Pentium III launched in 1999 without any vector > > > > > instructions. > > > > > > > > > > We are still missing something here. > > > > > > > > > There is a line > > > > #define vector > > > > __attribute__((vector_size(4*sizeof(int > > > > I guess it is the syntax needs to be supported. > > > > > > This is always supported. If the target does not have vector > > > instructions GCC will just expand vector arithmetic as a loop. > > > > > > Maybe we should just move this test into gcc.dg/vect where the > > > framework > > > automatically add options like -mlsx or -msse2? > > > > > > > The "-mlsx" option is turned on by default after vectorization > > testing > > is turned on. However, the use of dg-options in some files resets > > the > > compilation options for testing this file. Therefore, to detect > > vectorization on LoongArch, it is necessary to add an additional "- > > mlsx" option. > > Then it should use dg-additional-options instead of dg-options. > According to your advice, I have tried the following two ways: (1)Replace dg-options directly with dg-additional-options. The "-ansi- pedantic-errors" set in the dg.exp file is used, and the following problems occur: gcc.dg/pr104992.c:ISO C90 does not support complex types. gcc.dg/tree-ssa/scev-16.c:‘for’ loop initial declarations are only allowed in C99 or C11 mode Note: The ISO required by the program is inconsistent with the default standard, resulting in an error. (2)Move pr104992.c and scev-16.c to the gcc.dg/vect directory and replace dg-options with dg-additional-options. The problems are as follows: gcc.dg/vect/scev-16.c: Because there is no test rule starting with scev* in the vect.exp file, you need to add a new test rule or change the file name before the test can be performed. Summary: It is more appropriate to add the additional "-mlsx" option directly to the pr104992.c and scev-16.c files. This supports vectorization testing of the LoongArch architecture and does not modify the testing behavior of other architectures.
Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote： > On Mon, 2024-01-15 at 14:32 +0800, YunQiang Su wrote: > > Xi Ruoyao wrote at 12:11pm on Monday, January > > 15, 2024： > > > On Mon, 2024-01-15 at 09:29 +0800, chenxiaolong wrote: > > > > At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote： > > > > > At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong wrote： > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > > > > > * gcc.dg/pr104992.c: Added additional "-mlsx" compilation > > > > > > options. > > > > > > * gcc.dg/signbit-2.c: Dito. > > > > > > * gcc.dg/tree-ssa/scev-16.c: Dito. > > > > > > * gfortran.dg/graphite/vect-pr40979.f90: Dito. > > > > > > * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito. > > > > > > > > > > I don't feel it right about the changes to pr104992.c and > > > > > scev-16.c > > > > > because no other architectures add special options there. > > > > > Why are we > > > > > so special? > > > > Because on the LoongArch architecture, GCC requires the > > > > addition of > > > > vectorization options in order to generate vector code. Use the > > > > check_effective_target_vect_cmdline_needed command in the > > > > lib/target- > > > > supports.exp file to set whether the command line option is > > > > needed to > > > > enable vectorizations. For example, ia64,x86,aarch64, and riscv > > > > architectures, vectorization is enabled by default. > > > > > > But no. The default baseline of 32-bit x86 is i686, which is > > > basically > > > a Pentium III launched in 1999 without any vector instructions. > > > > > > We are still missing something here. > > > > > There is a line > > #define vector __attribute__((vector_size(4*sizeof(int > > I guess it is the syntax needs to be supported. > > This is always supported. If the target does not have vector > instructions GCC will just expand vector arithmetic as a loop. > > Maybe we should just move this test into gcc.dg/vect where the > framework > automatically add options like -mlsx or -msse2? > The "-mlsx" option is turned on by default after vectorization testing is turned on. However, the use of dg-options in some files resets the compilation options for testing this file. Therefore, to detect vectorization on LoongArch, it is necessary to add an additional "- mlsx" option.
Re: [PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
At 21:13 +0800 on Saturday, 2024-01-13, Xi Ruoyao wrote：
> At 15:28 +0800 on Saturday 2024-01-13, chenxiaolong wrote：
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/pr104992.c: Added additional "-mlsx" compilation
> > options.
> > * gcc.dg/signbit-2.c: Dito.
> > * gcc.dg/tree-ssa/scev-16.c: Dito.
> > * gfortran.dg/graphite/vect-pr40979.f90: Dito.
> > * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
>
> I don't feel it right about the changes to pr104992.c and scev-16.c
> because no other architectures add special options there. Why are we
> so special?
>
> > ---
> > gcc/testsuite/gcc.dg/pr104992.c| 1 +
> > gcc/testsuite/gcc.dg/signbit-2.c | 1 +
> > gcc/testsuite/gcc.dg/tree-ssa/scev-16.c| 1 +
> > gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90| 1 +
> > gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
> > 5 files changed, 5 insertions(+)
> >
> > diff --git a/gcc/testsuite/gcc.dg/pr104992.c
> > b/gcc/testsuite/gcc.dg/pr104992.c
> > index 82f8c75559c..a77992fa491 100644
> > --- a/gcc/testsuite/gcc.dg/pr104992.c
> > +++ b/gcc/testsuite/gcc.dg/pr104992.c
> > @@ -1,6 +1,7 @@
> > /* PR tree-optimization/104992 */
> > /* { dg-do compile } */
> > /* { dg-options "-O2 -Wno-psabi -fdump-tree-optimized" } */
> > +/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
> >
> > #define vector __attribute__((vector_size(4*sizeof(int
> >
> > diff --git a/gcc/testsuite/gcc.dg/signbit-2.c
> > b/gcc/testsuite/gcc.dg/signbit-2.c
> > index 62bb4047d74..5511bb78149 100644
> > --- a/gcc/testsuite/gcc.dg/signbit-2.c
> > +++ b/gcc/testsuite/gcc.dg/signbit-2.c
> > @@ -5,6 +5,7 @@
> > /* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-
> > *-* x86_64-*-* } } } */
> > /* { dg-additional-options "-march=armv8-a" { target aarch64_sve }
> > } */
> > /* { dg-additional-options "-maltivec" { target powerpc_altivec_ok
> > } } */
> > +/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
> > /* { dg-skip-if "no fallback for MVE" { arm_mve } } */
> >
> > #include
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> > b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> > index 120f40c0b6c..06cfbbcfae5 100644
> > --- a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
> > @@ -1,6 +1,7 @@
> > /* { dg-do compile } */
> > /* { dg-require-effective-target vect_int } */
> > /* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details" }
> > */
> > +/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
> > */
> >
> > int A[1024 * 2];
> >
> > diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
> > b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
> > index a42290948c4..6f2ad1166a4 100644
> > --- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
> > +++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
> > @@ -1,6 +1,7 @@
> > ! { dg-do compile }
> > ! { dg-require-effective-target vect_double }
> > ! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-
> > * } && ilp32 } } }
> > +! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
> >
> > module mqc_m
> > integer, parameter, private :: longreal =
> > selected_real_kind(15,90)
> > diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
> > b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
> > index 08965cc5e20..97b88821731 100644
> > --- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
> > +++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
> > @@ -2,6 +2,7 @@
> > ! { dg-require-effective-target vect_double }
> > ! { dg-options "-O3 --param vect-max-peeling-for-alignment=0
> > -fpredictive-commoning -fdump-tree-pcom-details -std=legacy" }
> > ! { dg-additional-options "-mprefer-avx128" { target { i?86-*-*
> > x86_64-*-* } } }
> > +! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
> > ! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
> >
> > *** RESID COMPUTES THE RESIDUAL: R = V - AU
Because on the LoongArch architecture, GCC requires the addition of
vectorization options in order to generate vector code. Use the
check_effective_target_vect_cmdline_needed command in the lib/target-
supports.exp file to set whether the command line option is needed to
enable vectorizations. For example, ia64,x86,aarch64, and riscv
architectures, vectorization is enabled by default.
[PATCH v2] LoongArch: testsuite:Fix fail in gen-vect-{2,25}.c file.
1.Added dg-do compile on LoongArch.
When binutils does not support vector instruction sets, an error occurs
because the assembler does not recognize vector instructions.
2.Added "-mlsx" option for vectorization on LoongArch.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/gen-vect-2.c: Added detection of compilation
behavior and "-mlsx" option on LoongArch.
* gcc.dg/tree-ssa/gen-vect-25.c: Dito.
---
gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c | 2 ++
gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
index b84f3184427..a35999a172a 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
@@ -1,6 +1,8 @@
/* { dg-do run { target vect_cmdline_needed } } */
+/* { dg-do compile { target { loongarch_sx && {! loongarch_sx_hw } } } } */
/* { dg-options "-O2 -fno-tree-loop-distribute-patterns -ftree-vectorize
-fdump-tree-vect-details -fvect-cost-model=dynamic" } */
/* { dg-additional-options "-mno-sse" { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
#include
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
index 18fe1aa1502..9f14a54c413 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
@@ -1,6 +1,8 @@
/* { dg-do run { target vect_cmdline_needed } } */
+/* { dg-do compile { target { loongarch_sx && {! loongarch_sx_hw } } } } */
/* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details
-fvect-cost-model=dynamic" } */
/* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details
-fvect-cost-model=dynamic -mno-sse" { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
#include
--
2.20.1
[PATCH v2] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
gcc/testsuite/ChangeLog:
* gcc.dg/pr104992.c: Added additional "-mlsx" compilation options.
* gcc.dg/signbit-2.c: Dito.
* gcc.dg/tree-ssa/scev-16.c: Dito.
* gfortran.dg/graphite/vect-pr40979.f90: Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
---
gcc/testsuite/gcc.dg/pr104992.c| 1 +
gcc/testsuite/gcc.dg/signbit-2.c | 1 +
gcc/testsuite/gcc.dg/tree-ssa/scev-16.c| 1 +
gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90| 1 +
gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
5 files changed, 5 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/pr104992.c b/gcc/testsuite/gcc.dg/pr104992.c
index 82f8c75559c..a77992fa491 100644
--- a/gcc/testsuite/gcc.dg/pr104992.c
+++ b/gcc/testsuite/gcc.dg/pr104992.c
@@ -1,6 +1,7 @@
/* PR tree-optimization/104992 */
/* { dg-do compile } */
/* { dg-options "-O2 -Wno-psabi -fdump-tree-optimized" } */
+/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
#define vector __attribute__((vector_size(4*sizeof(int
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
index 62bb4047d74..5511bb78149 100644
--- a/gcc/testsuite/gcc.dg/signbit-2.c
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -5,6 +5,7 @@
/* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-*-*
x86_64-*-* } } } */
/* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
/* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
+/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
/* { dg-skip-if "no fallback for MVE" { arm_mve } } */
#include
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
index 120f40c0b6c..06cfbbcfae5 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-require-effective-target vect_int } */
/* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details" } */
+/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
int A[1024 * 2];
diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
index a42290948c4..6f2ad1166a4 100644
--- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
@@ -1,6 +1,7 @@
! { dg-do compile }
! { dg-require-effective-target vect_double }
! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-* } && ilp32
} } }
+! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
module mqc_m
integer, parameter, private :: longreal = selected_real_kind(15,90)
diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
index 08965cc5e20..97b88821731 100644
--- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
+++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
@@ -2,6 +2,7 @@
! { dg-require-effective-target vect_double }
! { dg-options "-O3 --param vect-max-peeling-for-alignment=0
-fpredictive-commoning -fdump-tree-pcom-details -std=legacy" }
! { dg-additional-options "-mprefer-avx128" { target { i?86-*-* x86_64-*-* } }
}
+! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
*** RESID COMPUTES THE RESIDUAL: R = V - AU
--
2.20.1
[PATCH v1] LoongArch: testsuite:Fix fail in gen-vect-{2,25}.c file.
1.Delete "dg-do run".
When binutils do not support vectorization, an error occurs during
the assembly phase that does not recognize vector instructions.
2.Added "-mlsx" option for vectorization on LoongArch.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/gen-vect-2.c: Remove the program's default setting
run state and add the "-mlsx" compilation option for the additional
LoongArch architecture.
* gcc.dg/tree-ssa/gen-vect-25.c: Dito.
---
gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c | 3 ++-
gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
index b84f3184427..b83e355e93c 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
@@ -1,6 +1,7 @@
-/* { dg-do run { target vect_cmdline_needed } } */
+/* { target vect_cmdline_needed } */
/* { dg-options "-O2 -fno-tree-loop-distribute-patterns -ftree-vectorize
-fdump-tree-vect-details -fvect-cost-model=dynamic" } */
/* { dg-additional-options "-mno-sse" { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
#include
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
index 18fe1aa1502..edbc1dce28f 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
@@ -1,6 +1,7 @@
-/* { dg-do run { target vect_cmdline_needed } } */
+/* { target vect_cmdline_needed } */
/* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details
-fvect-cost-model=dynamic" } */
/* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details
-fvect-cost-model=dynamic -mno-sse" { target { i?86-*-* x86_64-*-* } } } */
+/* { dg-additional-options "-mlsx" { target { loongarch*-*-* } } } */
#include
--
2.20.1
[PATCH v1] LoongArch: testsuite:Added additional vectorization "-mlsx" option.
gcc/testsuite/ChangeLog:
* gcc.dg/pr104992.c: Added additional "-mlsx" compilation options.
* gcc.dg/signbit-2.c: Dito.
* gcc.dg/tree-ssa/scev-16.c: Dito.
* gfortran.dg/graphite/vect-pr40979.f90: Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
---
gcc/testsuite/gcc.dg/pr104992.c| 1 +
gcc/testsuite/gcc.dg/signbit-2.c | 1 +
gcc/testsuite/gcc.dg/tree-ssa/scev-16.c| 1 +
gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90| 1 +
gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
5 files changed, 5 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/pr104992.c b/gcc/testsuite/gcc.dg/pr104992.c
index 82f8c75559c..a77992fa491 100644
--- a/gcc/testsuite/gcc.dg/pr104992.c
+++ b/gcc/testsuite/gcc.dg/pr104992.c
@@ -1,6 +1,7 @@
/* PR tree-optimization/104992 */
/* { dg-do compile } */
/* { dg-options "-O2 -Wno-psabi -fdump-tree-optimized" } */
+/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
#define vector __attribute__((vector_size(4*sizeof(int
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
index 62bb4047d74..5511bb78149 100644
--- a/gcc/testsuite/gcc.dg/signbit-2.c
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -5,6 +5,7 @@
/* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-*-*
x86_64-*-* } } } */
/* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
/* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
+/* { dg-additional-options "-mlsx" { target loongarch_sx } } */
/* { dg-skip-if "no fallback for MVE" { arm_mve } } */
#include
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
index 120f40c0b6c..acaa1156419 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-require-effective-target vect_int } */
/* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details" } */
+/* { dg-additional-options "-mlsx" { target loongarch*-*-* } } */
int A[1024 * 2];
diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
index a42290948c4..4c251aacbe3 100644
--- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
@@ -1,6 +1,7 @@
! { dg-do compile }
! { dg-require-effective-target vect_double }
! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-* } && ilp32
} } }
+! { dg-additional-options "-mlsx" { target loongarch*-*-* } }
module mqc_m
integer, parameter, private :: longreal = selected_real_kind(15,90)
diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
index 08965cc5e20..97b88821731 100644
--- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
+++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
@@ -2,6 +2,7 @@
! { dg-require-effective-target vect_double }
! { dg-options "-O3 --param vect-max-peeling-for-alignment=0
-fpredictive-commoning -fdump-tree-pcom-details -std=legacy" }
! { dg-additional-options "-mprefer-avx128" { target { i?86-*-* x86_64-*-* } }
}
+! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
*** RESID COMPUTES THE RESIDUAL: R = V - AU
--
2.20.1
[PATCH v1] LoongArch: testsuite:Fixed a bug that added a target check error.
After the code is committed in r14-6948, GCC regression testing on some
architectures will produce the following error:
"error executing dg-final: unknown effective target keyword `loongarch*-*-*'"
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Removed an issue with "target keyword"
checking errors on LoongArch architecture.
---
gcc/testsuite/lib/target-supports.exp | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 5c6bb602cc0..dbc4f016091 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -7994,7 +7994,6 @@ proc check_effective_target_vect_widen_mult_qi_to_hi { } {
|| ([istarget aarch64*-*-*]
&& ![check_effective_target_aarch64_sve])
|| [is-effective-target arm_neon]
- || [is-effective-target loongarch*-*-*]
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx]))
|| [istarget amdgcn-*-*] }}]
@@ -8019,7 +8018,6 @@ proc check_effective_target_vect_widen_mult_hi_to_si { } {
&& ![check_effective_target_aarch64_sve])
|| [istarget i?86-*-*] || [istarget x86_64-*-*]
|| [is-effective-target arm_neon]
-|| [is-effective-target loongarch*-*-*]
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx]))
|| [istarget amdgcn-*-*] }}]
--
2.20.1
[PATCH v2] LoongArch: testsuite:Added support for loongarch.
The function of this test is to check that the compiler supports vectorization
using SLP and vec_{load/store/*}_lanes. However, vec_{load/store/*}_lanes are
not supported on LoongArch, such as the corresponding "st4/ld4" directives on
aarch64.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/slp-21.c: Add loongarch.
---
gcc/testsuite/gcc.dg/vect/slp-21.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/slp-21.c
b/gcc/testsuite/gcc.dg/vect/slp-21.c
index 712a73b69d7..58751688414 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-21.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-21.c
@@ -213,7 +213,7 @@ int main (void)
Not all vect_perm targets support that, and it's a bit too specific to have
its own effective-target selector, so we just test targets directly. */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" {
target { powerpc64*-*-* s390*-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" {
target { vect_strided4 && { ! { powerpc64*-*-* s390*-*-* } } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" {
target { powerpc64*-*-* s390*-*-* loongarch*-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" {
target { vect_strided4 && { ! { powerpc64*-*-* s390*-*-* loongarch*-*-* } } } }
} } */
/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" {
target { ! { vect_strided4 } } } } } */
--
2.20.1
[PATCH v3] LoongArch: testsuite:Added support for vector object detection.
- Change the default vectorization "-mlasx" option to "-mlsx" because there
are many non-aligned memory accesses when using 256-bit vectorization.
- The following detection procedure is added to the target-supports.exp file:
1.check_effective_target_scalar_all_fma
2.check_effective_target_vect_int
3.check_effective_target_vect_intfloat_cvt
4.check_effective_target_vect_doubleint_cvt
5.check_effective_target_vect_intdouble_cvt
6.check_effective_target_vect_uintfloat_cvt
7.check_effective_target_vect_floatint_cvt
8.check_effective_target_vect_floatuint_cvt
9.check_effective_target_vect_shift
10.check_effective_target_vect_var_shift
11.check_effective_target_whole_vector_shift
12.check_effective_target_vect_bswap
13.check_effective_target_vect_bool_cmp
14.check_effective_target_vect_char_add
15.check_effective_target_vect_shift_char
16.check_effective_target_vect_long
17.check_effective_target_vect_float
18.check_effective_target_vect_double
19.check_effective_target_vect_long_long
20.check_effective_target_vect_perm
21.check_effective_target_vect_perm_byte
22.check_effective_target_vect_perm_short
23.check_effective_target_vect_widen_sum_hi_to_si
24.check_effective_target_vect_widen_sum_qi_to_hi
25.check_effective_target_vect_widen_sum_qi_to_hi
26.check_effective_target_vect_widen_mult_qi_to_hi
27.check_effective_target_vect_widen_mult_hi_to_si
28.check_effective_target_vect_widen_mult_qi_to_hi_pattern
29.check_effective_target_vect_widen_mult_hi_to_si_pattern
30.check_effective_target_vect_widen_mult_si_to_di_pattern
31.check_effective_target_vect_sdot_qi
32.check_effective_target_vect_udot_qi
33.check_effective_target_vect_sdot_hi
34.check_effective_target_vect_udot_hi
35.check_effective_target_vect_usad_char
36.check_effective_target_vect_avg_qi
37.check_effective_target_vect_pack_trunc
38.check_effective_target_vect_unpack
39.check_effective_target_vect_hw_misalign
40.check_effective_target_vect_gather_load_ifn
40.check_effective_target_vect_condition
42.check_effective_target_vect_cond_mixed
43.check_effective_target_vect_char_mult
44.check_effective_target_vect_short_mult
45.check_effective_target_vect_int_mult
46.check_effective_target_vect_long_mult
47.check_effective_target_vect_int_mod
48.check_effective_target_vect_extract_even_odd
49.check_effective_target_vect_interleave
50.check_effective_target_vect_call_copysignf
51.check_effective_target_vect_call_sqrtf
52.check_effective_target_vect_call_lrint
53.check_effective_target_vect_call_btrunc
54.check_effective_target_vect_call_btruncf
55.check_effective_target_vect_call_ceil
56.check_effective_target_vect_call_ceilf
57.check_effective_target_vect_call_floor
58.check_effective_target_vect_call_floorf
59.check_effective_target_vect_call_lceil
60.check_effective_target_vect_call_lfloor
61.check_effective_target_vect_logical_reduc
62.check_effective_target_section_anchors
63.check_vect_support_and_set_flags
64.check_effective_target_vect_max_reduc
65.check_effective_target_loongarch_sx
66.check_effective_target_loongarch_sx_hw
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add LoongArch to the list of supported
targets.
---
gcc/testsuite/lib/target-supports.exp | 217 +++---
1 file changed, 162 insertions(+), 55 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 167e630f5a5..9addf35ade4 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3815,7 +3815,11 @@ proc add_options_for_bfloat16 { flags } {
# (fma, fms, fnma, and fnms) for both float and double.
proc check_effective_target_scalar_all_fma { } {
-return [istarget aarch64*-*-*]
+if { [istarget aarch64*-*-*]
+|| [istarget loongarch*-*-*]} {
+ return 1
+}
+return 0
}
# Return 1 if the target supports compiling fixed-point,
@@ -4051,6 +4055,8 @@ proc check_effective_target_vect_int { } {
&& [check_effective_target_s390_vx])
|| ([istarget riscv*-*-*]
&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx])
}}]
}
@@ -4218,7 +4224,9 @@ proc check_effective_target_vect_intfloat_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vxe2])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx]) }}]
}
# Return 1 if the target supports signed double->int conversion
@@ -4239,7 +4247,9 @@ proc check_effective_target_vect_doubleint_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_t
[PATCH v2 6/7] LoongArch: testsuite:Added additional vectorization "-mlasx" compilation option.
In the LoongArch architecture, the reason for not adding the 128-bit
vector-width-*hi* instruction template in the GCC back end is that it causes
program performance loss, so we can only add the "-mlasx" compilation option
to use 256-bit vectorization functions in test files.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-pattern-1.c: If you are testing on the
LoongArch architecture, you need to add the "-mlasx" compilation
option to generate vectorized code.
* gcc.dg/vect/slp-widen-mult-half.c: Dito.
* gcc.dg/vect/vect-widen-mult-const-s16.c: Dito.
* gcc.dg/vect/vect-widen-mult-const-u16.c: Dito.
* gcc.dg/vect/vect-widen-mult-half-u8.c: Dito.
* gcc.dg/vect/vect-widen-mult-half.c: Dito.
* gcc.dg/vect/vect-widen-mult-u16.c: Dito.
* gcc.dg/vect/vect-widen-mult-u8-s16-s32.c: Dito.
* gcc.dg/vect/vect-widen-mult-u8-u32.c: Dito.
* gcc.dg/vect/vect-widen-mult-u8.c: Dito.
---
gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c | 1 +
gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c| 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c| 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c| 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u8-s16-s32.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u8-u32.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u8.c | 1 +
10 files changed, 10 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
index a3ff0f5b3da..5ae99225273 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
@@ -1,4 +1,5 @@
/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-* } } */
#include
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
b/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
index 72811eb852e..b69ade33886 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
@@ -1,6 +1,7 @@
/* Disabling epilogues until we find a better way to deal with scans. */
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-* } } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
index dfbb2171c00..53c9b84ca01 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
@@ -2,6 +2,7 @@
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
/* { dg-additional-options "-fno-ipa-icf" } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
index c2ad58f69e7..e9db8285b66 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
@@ -2,6 +2,7 @@
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
/* { dg-additional-options "-fno-ipa-icf" } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
index bfdcbaa09fb..607f3178f90 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
@@ -2,6 +2,7 @@
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
/* { dg-additional-options "-fno-ipa-icf" } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
index e46b0cc3135..cd13d826937 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
@@ -1,6 +1,7 @@
/* Disabling epilogues until we find a better way to deal with scans. */
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c
index 14411ef43ed..258d253f401 100644
--- a/gcc/testsu
[PATCH v2 5/7] LoongArch: testsuite:Delete the default run behavior in pr60510.f.
When binutils does not support vector instruction sets, the test program fails
because it does not recognize vectorization at the assembly stage. Therefore,
the default run behavior of the program is deleted, so that the behavior of
the program depends on whether the software supports vectorization.
gcc/testsuite/ChangeLog:
* gfortran.dg/vect/pr60510.f: Delete the default behavior of the
program.
---
gcc/testsuite/gfortran.dg/vect/pr60510.f | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/vect/pr60510.f
b/gcc/testsuite/gfortran.dg/vect/pr60510.f
index 6cae82acece..d4fd42a664a 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr60510.f
+++ b/gcc/testsuite/gfortran.dg/vect/pr60510.f
@@ -1,4 +1,3 @@
-! { dg-do run }
! { dg-require-effective-target vect_double }
! { dg-require-effective-target vect_intdouble_cvt }
! { dg-additional-options "-fno-inline -ffast-math" }
--
2.20.1
[PATCH v2 4/7] LoongArch: testsuite:Fix FAIL in file bind_c_array_params_2.f90.
On the LoongArch architecture, an error was found in the
bind_c_array_params_2.f90 file because there was no proper assembly code
for the regular expression detection function call, such as bl %plt(myBindC).
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_array_params_2.f90: Add code test rules to
support testing of the loongArch architecture.
---
gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
index 0825efc7a2f..aa6a37b4850 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
+++ b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
@@ -2,6 +2,7 @@
! { dg-options "-std=f2008ts -fdump-tree-original" }
! { dg-additional-options "-mno-explicit-relocs" { target alpha*-*-* } }
! { dg-additional-options "-mno-relax-pic-calls" { target mips*-*-* } }
+! { dg-additional-options "-fplt -mcmodel=normal" { target loongarch*-*-* } }
!
! Check that assumed-shape variables are correctly passed to BIND(C)
! as defined in TS 29913
@@ -16,7 +17,8 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { !
{ hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming* } } }
} }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { !
{ hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming*
loongarch*-*-* } } } } }
+! { dg-final { scan-assembler-times "bl\t%plt\\(myBindC\\)" 1 { target
loongarch*-*-* } } }
! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-* } } }
}
! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin*
*-*-ming* } } } }
! { dg-final { scan-assembler-times "brasl\t%r\[0-9\]*,myBindC" 1 { target {
s390*-*-* } } } }
--
2.20.1
[PATCH v2 3/7] LoongArch: testsuite:Added detection support for LoongArch architecture in vect-{82, 83}.c.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-82.c: Add the LoongArch architecture to the
object detection framework.
* gcc.dg/vect/vect-83.c: Dito.
---
gcc/testsuite/gcc.dg/vect/vect-82.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-83.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/vect-82.c
b/gcc/testsuite/gcc.dg/vect/vect-82.c
index 4b2d5a8a464..5c761e92a3a 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-82.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-82.c
@@ -1,4 +1,4 @@
-/* { dg-skip-if "powerpc and integer vectorization only" { ! { powerpc*-*-* &&
vect_int } } } */
+/* { dg-skip-if "powerpc/loongarch and integer vectorization only" { ! { {
powerpc*-*-* || loongarch*-*-* } && vect_int } } } */
/* { dg-additional-options "-fdump-tree-optimized-details-blocks" } */
#include
diff --git a/gcc/testsuite/gcc.dg/vect/vect-83.c
b/gcc/testsuite/gcc.dg/vect/vect-83.c
index 1a173daa140..7fe1b050cee 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-83.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-83.c
@@ -1,4 +1,4 @@
-/* { dg-skip-if "powerpc and integer vectorization only" { ! { powerpc*-*-* &&
vect_int } } } */
+/* { dg-skip-if "powerpc/loongarch and integer vectorization only" { ! { {
powerpc*-*-* || loongarch*-*-* } && vect_int } } } */
/* { dg-additional-options "-fdump-tree-optimized-details-blocks" } */
#include
--
2.20.1
[PATCH v2 1/7] LoongArch: testsuite:Added support for vector object detection.
In the GCC of LoongArch architecture, the detection function of common
vectorization test cases is enabled. The following detection procedure
is added to the target-supports.exp file:
1.check_effective_target_scalar_all_fma
2.check_effective_target_vect_int
3.check_effective_target_vect_intfloat_cvt
4.check_effective_target_vect_doubleint_cvt
5.check_effective_target_vect_intdouble_cvt
6.check_effective_target_vect_uintfloat_cvt
7.check_effective_target_vect_floatint_cvt
8.check_effective_target_vect_floatuint_cvt
9.check_effective_target_vect_shift
10.check_effective_target_vect_var_shift
11.check_effective_target_whole_vector_shift
12.check_effective_target_vect_bswap
13.check_effective_target_vect_bool_cmp
14.check_effective_target_vect_char_add
15.check_effective_target_vect_shift_char
16.check_effective_target_vect_long
17.check_effective_target_vect_float
18.check_effective_target_vect_double
19.check_effective_target_vect_long_long
20.check_effective_target_vect_perm
21.check_effective_target_vect_perm_byte
22.check_effective_target_vect_perm_short
23.check_effective_target_vect_widen_sum_hi_to_si
24.check_effective_target_vect_widen_sum_qi_to_hi
25.check_effective_target_vect_widen_sum_qi_to_hi
26.check_effective_target_vect_widen_mult_qi_to_hi
27.check_effective_target_vect_widen_mult_hi_to_si
28.check_effective_target_vect_widen_mult_qi_to_hi_pattern
29.check_effective_target_vect_widen_mult_hi_to_si_pattern
30.check_effective_target_vect_widen_mult_si_to_di_pattern
31.check_effective_target_vect_sdot_qi
32.check_effective_target_vect_udot_qi
33.check_effective_target_vect_sdot_hi
34.check_effective_target_vect_udot_hi
35.check_effective_target_vect_usad_char
36.check_effective_target_vect_avg_qi
37.check_effective_target_vect_pack_trunc
38.check_effective_target_vect_unpack
39.check_effective_target_vect_hw_misalign
40.check_effective_target_vect_gather_load_ifn
40.check_effective_target_vect_condition
42.check_effective_target_vect_cond_mixed
43.check_effective_target_vect_char_mult
44.check_effective_target_vect_short_mult
45.check_effective_target_vect_int_mult
46.check_effective_target_vect_long_mult
47.check_effective_target_vect_int_mod
48.check_effective_target_vect_extract_even_odd
49.check_effective_target_vect_interleave
50.check_effective_target_vect_call_copysignf
51.check_effective_target_vect_call_sqrtf
52.check_effective_target_vect_call_lrint
53.check_effective_target_vect_call_btrunc
54.check_effective_target_vect_call_btruncf
55.check_effective_target_vect_call_ceil
56.check_effective_target_vect_call_ceilf
57.check_effective_target_vect_call_floor
58.check_effective_target_vect_call_floorf
59.check_effective_target_vect_call_lceil
60.check_effective_target_vect_call_lfloor
61.check_effective_target_vect_logical_reduc
62.check_effective_target_section_anchors
63.check_vect_support_and_set_flags
64.check_effective_target_vect_max_reduc
65.check_effective_target_loongarch_sx
66.check_effective_target_loongarch_sx_hw
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add LoongArch to the list of supported
targets.
---
gcc/testsuite/lib/target-supports.exp | 217 +++---
1 file changed, 162 insertions(+), 55 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 167e630f5a5..9addf35ade4 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3815,7 +3815,11 @@ proc add_options_for_bfloat16 { flags } {
# (fma, fms, fnma, and fnms) for both float and double.
proc check_effective_target_scalar_all_fma { } {
-return [istarget aarch64*-*-*]
+if { [istarget aarch64*-*-*]
+|| [istarget loongarch*-*-*]} {
+ return 1
+}
+return 0
}
# Return 1 if the target supports compiling fixed-point,
@@ -4051,6 +4055,8 @@ proc check_effective_target_vect_int { } {
&& [check_effective_target_s390_vx])
|| ([istarget riscv*-*-*]
&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx])
}}]
}
@@ -4218,7 +4224,9 @@ proc check_effective_target_vect_intfloat_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vxe2])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx]) }}]
}
# Return 1 if the target supports signed double->int conversion
@@ -4239,7 +4247,9 @@ proc check_effective_target_vect_doubleint_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget
[PATCH v2 7/7] LoongArch: testsuite:Give up the detection of the gcc.dg/fma-{3, 4, 6, 7}.c file.
On the LoongArch architecture, the above four test cases need to be waived
during testing. There are two situations:
1. The function of fma-{3,6}.c test is to find the value of c-a*b, but on
the LoongArch architecture, the function of the existing fnmsub instruction
is to find the value of -(a*b - c);
2. The function of fma-{4,7}.c test is to find the value of -(a*b)-c, but on
the LoongArch architecture, the function of the existing fnmadd instruction
is to find the value of -(a*b + c);
Through the analysis of the above two cases, there will be positive and
negative zero inequality.
gcc/testsuite/ChangeLog
* gcc.dg/fma-3.c: The intermediate file corresponding to the
function does not produce the corresponding FNMA symbol, so the test
rules should be skipped when testing.
* gcc.dg/fma-4.c: The intermediate file corresponding to the
function does not produce the corresponding FNMS symbol, so skip the
test rules when testing.
* gcc.dg/fma-6.c: The cause is the same as fma-3.c.
* gcc.dg/fma-7.c: The cause is the same as fma-4.c
---
gcc/testsuite/gcc.dg/fma-3.c | 2 +-
gcc/testsuite/gcc.dg/fma-4.c | 2 +-
gcc/testsuite/gcc.dg/fma-6.c | 2 +-
gcc/testsuite/gcc.dg/fma-7.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/fma-3.c b/gcc/testsuite/gcc.dg/fma-3.c
index 699aa2c9530..6649b54b6f9 100644
--- a/gcc/testsuite/gcc.dg/fma-3.c
+++ b/gcc/testsuite/gcc.dg/fma-3.c
@@ -12,4 +12,4 @@ f2 (double a, double b, double c)
return c - a * b;
}
-/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 2 "widening_mul" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 2 "widening_mul" { target
{ scalar_all_fma && { ! loongarch*-*-* } } } } } */
diff --git a/gcc/testsuite/gcc.dg/fma-4.c b/gcc/testsuite/gcc.dg/fma-4.c
index bff928f1fac..f1701c1961a 100644
--- a/gcc/testsuite/gcc.dg/fma-4.c
+++ b/gcc/testsuite/gcc.dg/fma-4.c
@@ -12,4 +12,4 @@ f2 (double a, double b, double c)
return -(a * b) - c;
}
-/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 2 "widening_mul" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 2 "widening_mul" { target
{ scalar_all_fma && { ! loongarch*-*-* } } } } } */
diff --git a/gcc/testsuite/gcc.dg/fma-6.c b/gcc/testsuite/gcc.dg/fma-6.c
index 87258cec4a2..9e49b62b6de 100644
--- a/gcc/testsuite/gcc.dg/fma-6.c
+++ b/gcc/testsuite/gcc.dg/fma-6.c
@@ -64,4 +64,4 @@ f10 (double a, double b, double c)
return -__builtin_fma (a, b, -c);
}
-/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 14 "optimized" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 14 "optimized" { target {
scalar_all_fma && { ! loongarch*-*-* } } } } } */
diff --git a/gcc/testsuite/gcc.dg/fma-7.c b/gcc/testsuite/gcc.dg/fma-7.c
index f409cc8ee3c..86aacad7b90 100644
--- a/gcc/testsuite/gcc.dg/fma-7.c
+++ b/gcc/testsuite/gcc.dg/fma-7.c
@@ -64,4 +64,4 @@ f10 (double a, double b, double c)
return -__builtin_fma (a, b, c);
}
-/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 14 "optimized" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 14 "optimized" { target {
scalar_all_fma && { ! loongarch*-*-* } } } } } */
--
2.20.1
[PATCH v2 2/7] LoongArch: testsuite:Modify the test behavior of the vect-bic-bitmask-{12, 23}.c file.
Before modifying the test behavior of the program, dg-do is set to assemble in
vect-bic-bitmask-{12,23}.c. However, when the binutils library does not support
the vector instruction set, it will FAIL to recognize the vector instruction
and fail item will appear in the assembly stage. So set the program's dg-do to
compile.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-bic-bitmask-12.c: Change the default
setting of assembly to compile.
* gcc.dg/vect/vect-bic-bitmask-23.c: Dito.
---
gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
index 36ec5a8b19b..213e4c2a418 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
@@ -1,5 +1,5 @@
/* { dg-skip-if "missing optab for vectorization" { sparc*-*-* } } */
-/* { dg-do assemble } */
+/* { dg-do compile } */
/* { dg-additional-options "-O3 -fdump-tree-dce -w" } */
#include
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
index 5b4c3b6e19b..5dceb4bbcb6 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
@@ -1,5 +1,5 @@
/* { dg-skip-if "missing optab for vectorization" { sparc*-*-* } } */
-/* { dg-do assemble } */
+/* { dg-do compile } */
/* { dg-additional-options "-O1 -fdump-tree-dce -w" } */
#include
--
2.20.1
[PATCH v2 0/7] LoongArch:Enable testing for common
v1->v2:
On the basis of v1, the reason of the analysis problem is described in detail.
When using binutils, which does not support vectorization, and the gcc compiler
toolchain, which does support vectorization, the following two types of error
problems occur in gcc regression testing.
1.Failure of common tests in the gcc.dg/vect directory???
Regression testing of GCC has found that vect-bic-bitmask-{12/23}.c has errors
at compile time, and similar problems exist on various architectures (e.g. x86,
aarch64,riscv, etc.). The reason is that the behavior of the program is the
assembly state, and the vector instruction cannot be recognized in the assembly
stage and an error occurs.
2.FAIL items of common vectorization tests are supported.
When LoongArch architecture supports common vector test cases, GCC regression
testing has many failures. Reasons include a lack of detection of targets
Rules, lack of vectorization options, lack of specific compilation options,
check for instruction set differences and test behavior for program Settings,
etc. For details, see the following patches:
chenxiaolong (7):
LoongArch: testsuite:Added support for vector object detection.
LoongArch: testsuite:Modify the test behavior of the
vect-bic-bitmask-{12,23}.c file.
LoongArch: testsuite:Added detection support for LoongArch
architecture in vect-{82,83}.c.
LoongArch: testsuite:Fix FAIL in file bind_c_array_params_2.f90.
LoongArch: testsuite:Delete the default run behavior in pr60510.f.
LoongArch: testsuite:Added additional vectorization "-mlasx"
compilation option.
LoongArch: testsuite:Give up the detection of the
gcc.dg/fma-{3,4,6,7}.c file.
gcc/testsuite/gcc.dg/fma-3.c | 2 +-
gcc/testsuite/gcc.dg/fma-4.c | 2 +-
gcc/testsuite/gcc.dg/fma-6.c | 2 +-
gcc/testsuite/gcc.dg/fma-7.c | 2 +-
gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c | 1 +
.../gcc.dg/vect/slp-widen-mult-half.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-82.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-83.c | 2 +-
.../gcc.dg/vect/vect-bic-bitmask-12.c | 2 +-
.../gcc.dg/vect/vect-bic-bitmask-23.c | 2 +-
.../gcc.dg/vect/vect-widen-mult-const-s16.c | 1 +
.../gcc.dg/vect/vect-widen-mult-const-u16.c | 1 +
.../gcc.dg/vect/vect-widen-mult-half-u8.c | 1 +
.../gcc.dg/vect/vect-widen-mult-half.c| 1 +
.../gcc.dg/vect/vect-widen-mult-u16.c | 1 +
.../gcc.dg/vect/vect-widen-mult-u8-s16-s32.c | 1 +
.../gcc.dg/vect/vect-widen-mult-u8-u32.c | 1 +
.../gcc.dg/vect/vect-widen-mult-u8.c | 1 +
.../gfortran.dg/bind_c_array_params_2.f90 | 4 +-
gcc/testsuite/gfortran.dg/vect/pr60510.f | 1 -
gcc/testsuite/lib/target-supports.exp | 217 +-
21 files changed, 183 insertions(+), 65 deletions(-)
--
2.20.1
Re: [PATCH v1 1/8] LoongArch: testsuite:Add detection procedures supported by the target.
At 14:28 +0800 on 2023-12-29th, Chenghua Xu wrote:
> chenxiaolong writes:
>
> > In order to improve and check the function of vector quantization
> > in
> > LoongArch architecture, tests on vector instruction set are
> > provided
> > in target-support.exp.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * lib/target-supports.exp:Add LoongArch to the list of
> > supported
> > targets.
> ^ Should be a space after ":".
> > ---
> > gcc/testsuite/lib/target-supports.exp | 219 +++---
> >
> > 1 file changed, 161 insertions(+), 58 deletions(-)
> >
> > diff --git a/gcc/testsuite/lib/target-supports.exp
> > b/gcc/testsuite/lib/target-supports.exp
> > index 14e3e119792..b90aaf8cabe 100644
> > --- a/gcc/testsuite/lib/target-supports.exp
> > +++ b/gcc/testsuite/lib/target-supports.exp
> > @@ -3811,7 +3811,11 @@ proc add_options_for_bfloat16 { flags } {
> > # (fma, fms, fnma, and fnms) for both float and double.
> >
> > proc check_effective_target_scalar_all_fma { } {
> > -return [istarget aarch64*-*-*]
> > +if { [istarget aarch64*-*-*]
>
> Trailing whitespace.
>
> > +|| [istarget loongarch*-*-*]} {
> > + return 1
> > +}
> > +return 0
> > }
> >
> > # Return 1 if the target supports compiling fixed-point,
> > @@ -4017,7 +4021,7 @@ proc
> > check_effective_target_vect_cmdline_needed { } {
> > || ([istarget arm*-*-*] &&
> > [check_effective_target_arm_neon])
> > || [istarget aarch64*-*-*]
> > || [istarget amdgcn*-*-*]
> > -|| [istarget riscv*-*-*]} {
> > +|| [istarget riscv*-*-*] } {
>
> Misses something ?
>
> > return 0
> > } else {
> > return 1
> > @@ -4047,6 +4051,8 @@ proc check_effective_target_vect_int { } {
> > && [check_effective_target_s390_vx])
> > || ([istarget riscv*-*-*]
> > && [check_effective_target_riscv_v])
> > +|| ([istarget loongarch*-*-*]
> > +&& [check_effective_target_loongarch_sx])
> > }}]
> > }
> >
> > @@ -4176,7 +4182,9 @@ proc check_effective_target_vect_intfloat_cvt
> > { } {
> > || ([istarget s390*-*-*]
> > && [check_effective_target_s390_vxe2])
> > || ([istarget riscv*-*-*]
> > -&& [check_effective_target_riscv_v]) }}]
> > +&& [check_effective_target_riscv_v])
> > +|| ([istarget loongarch*-*-*]
> > +&& [check_effective_target_loongarch_sx]) }}]
> > }
> >
> > # Return 1 if the target supports signed double->int conversion
> > @@ -4197,7 +4205,9 @@ proc
> > check_effective_target_vect_doubleint_cvt { } {
> > || ([istarget s390*-*-*]
> > && [check_effective_target_s390_vx])
> > || ([istarget riscv*-*-*]
> > -&& [check_effective_target_riscv_v]) }}]
> > +&& [check_effective_target_riscv_v])
> > +|| ([istarget loongarch*-*-*]
> > +&& [check_effective_target_loongarch_sx]) }}]
> > }
> >
> > # Return 1 if the target supports signed int->double conversion
> > @@ -4218,7 +4228,9 @@ proc
> > check_effective_target_vect_intdouble_cvt { } {
> > || ([istarget s390*-*-*]
> > && [check_effective_target_s390_vx])
> > || ([istarget riscv*-*-*]
> > -&& [check_effective_target_riscv_v]) }}]
> > +&& [check_effective_target_riscv_v])
> > +|| ([istarget loongarch*-*-*]
> > +&& [check_effective_target_loongarch_sx]) }}]
> > }
> >
> > #Return 1 if we're supporting __int128 for target, 0 otherwise.
> > @@ -4251,7 +4263,9 @@ proc
> > check_effective_target_vect_uintfloat_cvt { } {
> > || ([istarget s390*-*-*]
> > && [check_effective_target_s390_vxe2])
> > || ([istarget riscv*-*-*]
> > -&& [check_effective_target_riscv_v]) }}]
> > +&& [check_effective_target_riscv_v])
> > +|| ([istarget loongarch*-*-*]
> > +&& [check_effective_target_loongarch_sx]) }}]
> > }
> >
> >
> > @@ -4270,7 +4284,9 @@ proc check_effective_target_vect_floatint_cvt
> > { } {
> > ||
[PATCH v1] LoongArch: testsuite:Add loongarch to gcc.dg/vect/slp-26.c.
In the LoongArch architecture, GCC supports the vectorization function tested
by vect/slp-26.c, but there is no detection of loongarch in dg-finals. Add
loongarch to the appropriate dg-finals.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/slp-26.c: Add loongarch.
---
gcc/testsuite/gcc.dg/vect/slp-26.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/slp-26.c
b/gcc/testsuite/gcc.dg/vect/slp-26.c
index c964635c91c..cfb763bf519 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-26.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-26.c
@@ -47,7 +47,7 @@ int main (void)
return 0;
}
-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { target {
! { mips_msa || { amdgcn-*-* || riscv_v } } } } } } */
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
mips_msa || { amdgcn-*-* || riscv_v } } } } } */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" {
target { ! { mips_msa || { amdgcn-*-* || riscv_v } } } } } } */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" {
target { mips_msa || { amdgcn-*-* || riscv_v } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 1 "vect" { target {
! { mips_msa || { amdgcn-*-* || { riscv_v || loongarch_sx } } } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {
mips_msa || { amdgcn-*-* || { riscv_v || loongarch_sx } } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" {
target { ! { mips_msa || { amdgcn-*-* || { riscv_v || loongarch_sx } } } } } }
} */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 1 "vect" {
target { mips_msa || { amdgcn-*-* || { riscv_v || loongarch_sx } } } } } } */
--
2.20.1
[PATCH v1] LoongArch: testsuite:Add loongarch to gcc.dg/vect/slp-21.c.
In the GCC code of LoongArch architecture, IFN_STORE_LANES optimization
operation is not supported, and four SLP statements are used for vectorization
in slp-21.c. So add loongarch*-*-* to the corresponding dg-finals.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/slp-21.c: Add loongarch.
---
gcc/testsuite/gcc.dg/vect/slp-21.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/slp-21.c
b/gcc/testsuite/gcc.dg/vect/slp-21.c
index 712a73b69d7..58751688414 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-21.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-21.c
@@ -213,7 +213,7 @@ int main (void)
Not all vect_perm targets support that, and it's a bit too specific to have
its own effective-target selector, so we just test targets directly. */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" {
target { powerpc64*-*-* s390*-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" {
target { vect_strided4 && { ! { powerpc64*-*-* s390*-*-* } } } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 4 "vect" {
target { powerpc64*-*-* s390*-*-* loongarch*-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 2 "vect" {
target { vect_strided4 && { ! { powerpc64*-*-* s390*-*-* loongarch*-*-* } } } }
} } */
/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 0 "vect" {
target { ! { vect_strided4 } } } } } */
--
2.20.1
[PATCH v1] LoongArch: testsuite:Add the "-ffast-math" compilation option for the file vect-fmin-3.c.
After the detection of maximum reduction is enabled on LoongArch architecture,
the regression test of GCC finds that vect-fmin-3.c fails. Currently, in the
target-supports.exp file, only aarch64,arm,riscv, and LoongArch architectures
are supported. Through analysis, the "-ffast-math" compilation option needs to
be added to the test case in order to successfully reduce using vectorization.
The original patch was submitted by author Richard Sandiford.
The initial patch information submitted is as follows:
commit e32b9eb32d7cd2d39bf9c70497890ac61b9ee14c
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-fmin-3.c:Adding an extra "-ffast-math" to the
compilation option ensures that the loop can be reduced to maximum
success.
---
gcc/testsuite/gcc.dg/vect/vect-fmin-3.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
b/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
index 2e282ba6878..edef57925c1 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
@@ -1,4 +1,5 @@
/* { dg-require-effective-target vect_float } */
+/* { dg-additional-options "-ffast-math" } */
#include "tree-vect.h"
--
2.20.1
[PATCH v1 8/8] LoongArch: testsuite:Modify the result check in the FMA file.
When gcc enabled the vectorization of the common layer, some FAIL items
appeared in GCC regression tests, such as gcc.dg/fma-{3,4,6,7}.c. On LoongArch
architecture, for example, the result of fmsub.s instruction is a*b-c, and
there is a problem of positive and negative zero inequality between the result
of c-a*b expected to be calculated, so the detection of such problems in
LoongArch architecture needs to be set to unsupported state.
gcc/testsuite/ChangeLog:
* gcc.dg/fma-3.c:The intermediate file corresponding to the
function does not produce the corresponding FNMA symbol, so the test
rules should be skipped when testing.
* gcc.dg/fma-4.c:The intermediate file corresponding to the
function does not produce the corresponding FNMS symbol, so skip the
test rules when testing.
* gcc.dg/fma-6.c:The cause is the same as fma-3.c.
* gcc.dg/fma-7.c:The cause is the same as fma-4.c
---
gcc/testsuite/gcc.dg/fma-3.c | 2 +-
gcc/testsuite/gcc.dg/fma-4.c | 2 +-
gcc/testsuite/gcc.dg/fma-6.c | 2 +-
gcc/testsuite/gcc.dg/fma-7.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/fma-3.c b/gcc/testsuite/gcc.dg/fma-3.c
index 699aa2c9530..6649b54b6f9 100644
--- a/gcc/testsuite/gcc.dg/fma-3.c
+++ b/gcc/testsuite/gcc.dg/fma-3.c
@@ -12,4 +12,4 @@ f2 (double a, double b, double c)
return c - a * b;
}
-/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 2 "widening_mul" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 2 "widening_mul" { target
{ scalar_all_fma && { ! loongarch*-*-* } } } } } */
diff --git a/gcc/testsuite/gcc.dg/fma-4.c b/gcc/testsuite/gcc.dg/fma-4.c
index bff928f1fac..f1701c1961a 100644
--- a/gcc/testsuite/gcc.dg/fma-4.c
+++ b/gcc/testsuite/gcc.dg/fma-4.c
@@ -12,4 +12,4 @@ f2 (double a, double b, double c)
return -(a * b) - c;
}
-/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 2 "widening_mul" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 2 "widening_mul" { target
{ scalar_all_fma && { ! loongarch*-*-* } } } } } */
diff --git a/gcc/testsuite/gcc.dg/fma-6.c b/gcc/testsuite/gcc.dg/fma-6.c
index 87258cec4a2..9e49b62b6de 100644
--- a/gcc/testsuite/gcc.dg/fma-6.c
+++ b/gcc/testsuite/gcc.dg/fma-6.c
@@ -64,4 +64,4 @@ f10 (double a, double b, double c)
return -__builtin_fma (a, b, -c);
}
-/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 14 "optimized" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMA \(} 14 "optimized" { target {
scalar_all_fma && { ! loongarch*-*-* } } } } } */
diff --git a/gcc/testsuite/gcc.dg/fma-7.c b/gcc/testsuite/gcc.dg/fma-7.c
index f409cc8ee3c..86aacad7b90 100644
--- a/gcc/testsuite/gcc.dg/fma-7.c
+++ b/gcc/testsuite/gcc.dg/fma-7.c
@@ -64,4 +64,4 @@ f10 (double a, double b, double c)
return -__builtin_fma (a, b, c);
}
-/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 14 "optimized" { target
scalar_all_fma } } } */
+/* { dg-final { scan-tree-dump-times { = \.FNMS \(} 14 "optimized" { target {
scalar_all_fma && { ! loongarch*-*-* } } } } } */
--
2.20.1
[PATCH v1 4/8] LoongArch: testsuite:Fix FAIL in file bind_c_array_params_2.f90.
In the GCC regression test result, it is found that the
bind_c_array_params_2.f90 test fails. After analysis, it is found that the
reason why the test fails is that the regular expression in the test result
cannot correctly detect the correct assembly code (such as bl %plt(myBindC))
generated on the LoongArch architecture, such as the assembly code generated
on the x86 function call (call myBindC).
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_array_params_2.f90:Add code test rules to
support testing of the loongArch architecture.
---
gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
index 0825efc7a2f..aa6a37b4850 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
+++ b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
@@ -2,6 +2,7 @@
! { dg-options "-std=f2008ts -fdump-tree-original" }
! { dg-additional-options "-mno-explicit-relocs" { target alpha*-*-* } }
! { dg-additional-options "-mno-relax-pic-calls" { target mips*-*-* } }
+! { dg-additional-options "-fplt -mcmodel=normal" { target loongarch*-*-* } }
!
! Check that assumed-shape variables are correctly passed to BIND(C)
! as defined in TS 29913
@@ -16,7 +17,8 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { !
{ hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming* } } }
} }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { !
{ hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming*
loongarch*-*-* } } } } }
+! { dg-final { scan-assembler-times "bl\t%plt\\(myBindC\\)" 1 { target
loongarch*-*-* } } }
! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-* } } }
}
! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin*
*-*-ming* } } } }
! { dg-final { scan-assembler-times "brasl\t%r\[0-9\]*,myBindC" 1 { target {
s390*-*-* } } } }
--
2.20.1
[PATCH v1 3/8] LoongArch: testsuite:Added test support for vect-{82, 83}.c.
When gcc enables the file test under gcc.dg/vect, it is found that vect-{82,
83}.c does not support the test. Through analysis, LoongArch architecture
supports the detection function of this test case. Therefore, the detection
of LoongArch architecture is added to the test rules to solve the situation
that the test is not supported.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-82.c:Add the LoongArch architecture to the
object detection framework.
* gcc.dg/vect/vect-83.c:Dito.
---
gcc/testsuite/gcc.dg/vect/vect-82.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-83.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/vect-82.c
b/gcc/testsuite/gcc.dg/vect/vect-82.c
index 4b2d5a8a464..5c761e92a3a 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-82.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-82.c
@@ -1,4 +1,4 @@
-/* { dg-skip-if "powerpc and integer vectorization only" { ! { powerpc*-*-* &&
vect_int } } } */
+/* { dg-skip-if "powerpc/loongarch and integer vectorization only" { ! { {
powerpc*-*-* || loongarch*-*-* } && vect_int } } } */
/* { dg-additional-options "-fdump-tree-optimized-details-blocks" } */
#include
diff --git a/gcc/testsuite/gcc.dg/vect/vect-83.c
b/gcc/testsuite/gcc.dg/vect/vect-83.c
index 1a173daa140..7fe1b050cee 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-83.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-83.c
@@ -1,4 +1,4 @@
-/* { dg-skip-if "powerpc and integer vectorization only" { ! { powerpc*-*-* &&
vect_int } } } */
+/* { dg-skip-if "powerpc/loongarch and integer vectorization only" { ! { {
powerpc*-*-* || loongarch*-*-* } && vect_int } } } */
/* { dg-additional-options "-fdump-tree-optimized-details-blocks" } */
#include
--
2.20.1
[PATCH v1 6/8] LoongArch: testsuite:Added additional vectorization "-mlasx" compilation option.
After the detection procedure under the gcc.dg/vect directory was added to
GCC, FAIL entries of vector multiplication transformations of different types
appeared in the gcc regression test results. After debugging analysis, the main
problem is that the 128-bit vector of LoongArch architecture does not realize
this function. To solve this problem, the "-mlasx" option is used to enable the
256-bit vectorization implementation.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/bb-slp-pattern-1.c:If you are testing on the
LoongArch architecture, you need to add the "-mlasx" compilation
option to generate vectorized code.
* gcc.dg/vect/slp-widen-mult-half.c:Dito.
* gcc.dg/vect/vect-widen-mult-const-s16.c:Dito.
* gcc.dg/vect/vect-widen-mult-const-u16.c:Dito.
* gcc.dg/vect/vect-widen-mult-half-u8.c:Dito.
* gcc.dg/vect/vect-widen-mult-half.c:Dito.
* gcc.dg/vect/vect-widen-mult-u16.c:Dito.
* gcc.dg/vect/vect-widen-mult-u8-s16-s32.c:Dito.
* gcc.dg/vect/vect-widen-mult-u8-u32.c:Dito.
* gcc.dg/vect/vect-widen-mult-u8.c:Dito.
---
gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c | 1 +
gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c| 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c| 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u16.c| 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u8-s16-s32.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u8-u32.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-widen-mult-u8.c | 1 +
10 files changed, 10 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
b/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
index a3ff0f5b3da..5ae99225273 100644
--- a/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
+++ b/gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c
@@ -1,4 +1,5 @@
/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-* } } */
#include
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
b/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
index 72811eb852e..b69ade33886 100644
--- a/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
+++ b/gcc/testsuite/gcc.dg/vect/slp-widen-mult-half.c
@@ -1,6 +1,7 @@
/* Disabling epilogues until we find a better way to deal with scans. */
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-* } } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
index dfbb2171c00..53c9b84ca01 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-s16.c
@@ -2,6 +2,7 @@
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
/* { dg-additional-options "-fno-ipa-icf" } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
index c2ad58f69e7..e9db8285b66 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-const-u16.c
@@ -2,6 +2,7 @@
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
/* { dg-additional-options "-fno-ipa-icf" } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
index bfdcbaa09fb..607f3178f90 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half-u8.c
@@ -2,6 +2,7 @@
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
/* { dg-additional-options "-fno-ipa-icf" } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
index e46b0cc3135..cd13d826937 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-widen-mult-half.c
@@ -1,6 +1,7 @@
/* Disabling epilogues until we find a better way to deal with scans. */
/* { dg-additional-options "--param vect-epilogues-nomask=0" } */
/* { dg-require-effective-target vect_int } */
+/* { dg-additional-options "-mlasx" { target loongarch*-*-*} } */
#include "tree-vect.h"
diff --git a/gcc/testsui
[PATCH v1 7/8] LoongArch: testsuite:Added additional vectorization "-mlsx" compilation option.
When GCC is able to detect vectorized test cases in the common layer, FAIL
entries appear in some test cases after regression testing. The cause of the
error is that the vectorization option was not set when testing the program,
and the vectorization code could not be generated, so additional support for
the "-mlsx" option needed to be added back on the LoongArch architecture.
gcc/testsuite/ChangeLog:
* gcc.dg/signbit-2.c:Added additional "-mlsx"
compilation options.
* gcc.dg/tree-ssa/scev-16.c:Dito.
* gfortran.dg/graphite/vect-pr40979.f90:Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f:Dito.
---
gcc/testsuite/gcc.dg/signbit-2.c | 1 +
gcc/testsuite/gcc.dg/tree-ssa/scev-16.c| 1 +
gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90| 1 +
gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
4 files changed, 4 insertions(+)
diff --git a/gcc/testsuite/gcc.dg/signbit-2.c b/gcc/testsuite/gcc.dg/signbit-2.c
index 62bb4047d74..2f65df16e43 100644
--- a/gcc/testsuite/gcc.dg/signbit-2.c
+++ b/gcc/testsuite/gcc.dg/signbit-2.c
@@ -5,6 +5,7 @@
/* { dg-additional-options "-msse2 -mno-avx512f" { target { i?86-*-*
x86_64-*-* } } } */
/* { dg-additional-options "-march=armv8-a" { target aarch64_sve } } */
/* { dg-additional-options "-maltivec" { target powerpc_altivec_ok } } */
+/* { dg-additional-options "-mlsx" { target loongarch*-*-* } } */
/* { dg-skip-if "no fallback for MVE" { arm_mve } } */
#include
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
index 120f40c0b6c..acaa1156419 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/scev-16.c
@@ -1,6 +1,7 @@
/* { dg-do compile } */
/* { dg-require-effective-target vect_int } */
/* { dg-options "-O2 -ftree-vectorize -fdump-tree-vect-details" } */
+/* { dg-additional-options "-mlsx" { target loongarch*-*-* } } */
int A[1024 * 2];
diff --git a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
index a42290948c4..4c251aacbe3 100644
--- a/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
+++ b/gcc/testsuite/gfortran.dg/graphite/vect-pr40979.f90
@@ -1,6 +1,7 @@
! { dg-do compile }
! { dg-require-effective-target vect_double }
! { dg-additional-options "-msse2" { target { { i?86-*-* x86_64-*-* } && ilp32
} } }
+! { dg-additional-options "-mlsx" { target loongarch*-*-* } }
module mqc_m
integer, parameter, private :: longreal = selected_real_kind(15,90)
diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
index 08965cc5e20..97b88821731 100644
--- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
+++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
@@ -2,6 +2,7 @@
! { dg-require-effective-target vect_double }
! { dg-options "-O3 --param vect-max-peeling-for-alignment=0
-fpredictive-commoning -fdump-tree-pcom-details -std=legacy" }
! { dg-additional-options "-mprefer-avx128" { target { i?86-*-* x86_64-*-* } }
}
+! { dg-additional-options "-mlsx" { target { loongarch*-*-* } } }
! { dg-additional-options "-mzarch" { target { s390*-*-* } } }
*** RESID COMPUTES THE RESIDUAL: R = V - AU
--
2.20.1
[PATCH v1 5/8] LoongArch: testsuite:Modify the test behavior in file pr60510.f.
When using binutils that does not support vectorization and gcc compiler
toolchain that supports vectorization, regression tests found that pr60510.f
had a FAIL entry. The reason is that the default setting of the program is
the execution state, which will cause problems in the assembly stage when the
vector instructions cannot be identified. In order to solve this problem, the
default behavior set to run was removed, and the behavior of the program
depends on whether the software supports vectorization or not.
gcc/testsuite/ChangeLog:
* gfortran.dg/vect/pr60510.f:Delete the default behavior of the
program.
---
gcc/testsuite/gfortran.dg/vect/pr60510.f | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/vect/pr60510.f
b/gcc/testsuite/gfortran.dg/vect/pr60510.f
index 6cae82acece..d4fd42a664a 100644
--- a/gcc/testsuite/gfortran.dg/vect/pr60510.f
+++ b/gcc/testsuite/gfortran.dg/vect/pr60510.f
@@ -1,4 +1,3 @@
-! { dg-do run }
! { dg-require-effective-target vect_double }
! { dg-require-effective-target vect_intdouble_cvt }
! { dg-additional-options "-fno-inline -ffast-math" }
--
2.20.1
[PATCH v1 2/8] LoongArch: testsuite:Modify the test behavior of the vect-bic-bitmask-{12, 23}.c file.
When the toolchain is built using binutils that does not support vectorization
and gcc that supports vectorization, the regression test results of GCC show
that the vect-bic-bitmask-{12,23}.c file fails. The reason is that it carries
out two stages of compilation and assembly test, in the assembly stage there is
no identification of vector instructions, but in fact only need to carry out
the compilation stage. To solve this problem, change the default set of
assembly to compile only, so that other architectures do not have similar
problems.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-bic-bitmask-12.c:Change the default
setting of assembly to compile.
* gcc.dg/vect/vect-bic-bitmask-23.c:Dito.
---
gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
index 36ec5a8b19b..213e4c2a418 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-12.c
@@ -1,5 +1,5 @@
/* { dg-skip-if "missing optab for vectorization" { sparc*-*-* } } */
-/* { dg-do assemble } */
+/* { dg-do compile } */
/* { dg-additional-options "-O3 -fdump-tree-dce -w" } */
#include
diff --git a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
index 5b4c3b6e19b..5dceb4bbcb6 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-bic-bitmask-23.c
@@ -1,5 +1,5 @@
/* { dg-skip-if "missing optab for vectorization" { sparc*-*-* } } */
-/* { dg-do assemble } */
+/* { dg-do compile } */
/* { dg-additional-options "-O1 -fdump-tree-dce -w" } */
#include
--
2.20.1
[PATCH v1 1/8] LoongArch: testsuite:Add detection procedures supported by the target.
In order to improve and check the function of vector quantization in
LoongArch architecture, tests on vector instruction set are provided
in target-support.exp.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp:Add LoongArch to the list of supported
targets.
---
gcc/testsuite/lib/target-supports.exp | 219 +++---
1 file changed, 161 insertions(+), 58 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 14e3e119792..b90aaf8cabe 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3811,7 +3811,11 @@ proc add_options_for_bfloat16 { flags } {
# (fma, fms, fnma, and fnms) for both float and double.
proc check_effective_target_scalar_all_fma { } {
-return [istarget aarch64*-*-*]
+if { [istarget aarch64*-*-*]
+|| [istarget loongarch*-*-*]} {
+ return 1
+}
+return 0
}
# Return 1 if the target supports compiling fixed-point,
@@ -4017,7 +4021,7 @@ proc check_effective_target_vect_cmdline_needed { } {
|| ([istarget arm*-*-*] && [check_effective_target_arm_neon])
|| [istarget aarch64*-*-*]
|| [istarget amdgcn*-*-*]
-|| [istarget riscv*-*-*]} {
+|| [istarget riscv*-*-*] } {
return 0
} else {
return 1
@@ -4047,6 +4051,8 @@ proc check_effective_target_vect_int { } {
&& [check_effective_target_s390_vx])
|| ([istarget riscv*-*-*]
&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx])
}}]
}
@@ -4176,7 +4182,9 @@ proc check_effective_target_vect_intfloat_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vxe2])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx]) }}]
}
# Return 1 if the target supports signed double->int conversion
@@ -4197,7 +4205,9 @@ proc check_effective_target_vect_doubleint_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx]) }}]
}
# Return 1 if the target supports signed int->double conversion
@@ -4218,7 +4228,9 @@ proc check_effective_target_vect_intdouble_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vx])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx]) }}]
}
#Return 1 if we're supporting __int128 for target, 0 otherwise.
@@ -4251,7 +4263,9 @@ proc check_effective_target_vect_uintfloat_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vxe2])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx]) }}]
}
@@ -4270,7 +4284,9 @@ proc check_effective_target_vect_floatint_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vxe2])
|| ([istarget riscv*-*-*]
-&& [check_effective_target_riscv_v]) }}]
+&& [check_effective_target_riscv_v])
+|| ([istarget loongarch*-*-*]
+&& [check_effective_target_loongarch_sx]) }}]
}
# Return 1 if the target supports unsigned float->int conversion
@@ -4287,7 +4303,9 @@ proc check_effective_target_vect_floatuint_cvt { } {
|| ([istarget s390*-*-*]
&& [check_effective_target_s390_vxe2])
|| ([istarget riscv*-*-*]
- && [check_effective_target_riscv_v]) }}]
+ && [check_effective_target_riscv_v])
+ || ([istarget loongarch*-*-*]
+ && [check_effective_target_loongarch_sx]) }}]
}
# Return 1 if the target supports vector integer char -> long long extend optab
@@ -4296,7 +4314,9 @@ proc check_effective_target_vect_floatuint_cvt { } {
proc check_effective_target_vect_ext_char_longlong { } {
return [check_cached_effective_target_indexed vect_ext_char_longlong {
expr { ([istarget riscv*-*-*]
- && [check_effective_target_riscv_v]) }}]
+ && [check_effective_target_riscv_v])
+ || ([istarget loongar
[PATCH v1 0/8] LoongArch:Enable testing for common
When using binutils, which does not support vectorization, and the gcc compiler
toolchain, which does support vectorization, the following two types of error
problems occur in gcc regression testing.
1.Failure of common tests in the gcc.dg/vect directory???
Regression testing of GCC has found that vect-bic-bitmask-{12/23}.c has errors
at compile time, and similar problems exist on various architectures (e.g. x86,
aarch64,riscv, etc.). The reason is that the behavior of the program is the
assembly state, and the vector instruction cannot be recognized in the assembly
stage and an error occurs.
2.FAIL items of common vectorization tests are supported.
When LoongArch architecture supports common vector test cases, GCC regression
testing has many failures. Reasons include a lack of detection of targets
Rules, lack of vectorization options, lack of specific compilation options,
check for instruction set differences and test behavior for program Settings,
etc. For details, see the following patches:
chenxiaolong (8):
LoongArch: testsuite:Add detection procedures supported by the target.
LoongArch: testsuite:Modify the test behavior of the
vect-bic-bitmask-{12,23}.c file.
LoongArch: testsuite:Added test support for vect-{82,83}.c.
LoongArch: testsuite:Fix FAIL in file bind_c_array_params_2.f90.
LoongArch: testsuite:Modify the test behavior in file pr60510.f.
LoongArch: testsuite:Added additional vectorization "-mlasx"
compilation option.
LoongArch: testsuite:Added additional vectorization "-mlsx"
compilation option.
LoongArch: testsuite:Modify the result check in the FMA file.
gcc/testsuite/gcc.dg/fma-3.c | 2 +-
gcc/testsuite/gcc.dg/fma-4.c | 2 +-
gcc/testsuite/gcc.dg/fma-6.c | 2 +-
gcc/testsuite/gcc.dg/fma-7.c | 2 +-
gcc/testsuite/gcc.dg/signbit-2.c | 1 +
gcc/testsuite/gcc.dg/tree-ssa/scev-16.c | 1 +
gcc/testsuite/gcc.dg/vect/bb-slp-pattern-1.c | 1 +
.../gcc.dg/vect/slp-widen-mult-half.c | 1 +
gcc/testsuite/gcc.dg/vect/vect-82.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-83.c | 2 +-
.../gcc.dg/vect/vect-bic-bitmask-12.c | 2 +-
.../gcc.dg/vect/vect-bic-bitmask-23.c | 2 +-
.../gcc.dg/vect/vect-widen-mult-const-s16.c | 1 +
.../gcc.dg/vect/vect-widen-mult-const-u16.c | 1 +
.../gcc.dg/vect/vect-widen-mult-half-u8.c | 1 +
.../gcc.dg/vect/vect-widen-mult-half.c| 1 +
.../gcc.dg/vect/vect-widen-mult-u16.c | 1 +
.../gcc.dg/vect/vect-widen-mult-u8-s16-s32.c | 1 +
.../gcc.dg/vect/vect-widen-mult-u8-u32.c | 1 +
.../gcc.dg/vect/vect-widen-mult-u8.c | 1 +
.../gfortran.dg/bind_c_array_params_2.f90 | 4 +-
.../gfortran.dg/graphite/vect-pr40979.f90 | 1 +
.../gfortran.dg/vect/fast-math-mgrid-resid.f | 1 +
gcc/testsuite/gfortran.dg/vect/pr60510.f | 1 -
gcc/testsuite/lib/target-supports.exp | 219 +-
25 files changed, 186 insertions(+), 68 deletions(-)
--
2.20.1
[PATCH v1] LoongArch: testsuite:Fix FAIL in lasx-xvstelm.c file.
After implementing the cost model on the LoongArch architecture, the GCC
compiler code has this feature turned on by default, which causes the
lasx-xvstelm.c file test to fail. Through analysis, this test case can
generate vectorization instructions required for detection only after
disabling the functionality of the cost model with the "-fno-vect-cost-model"
compilation option.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/lasx/lasx-xvstelm.c:Add compile
option "-fno-vect-cost-model" to dg-options.
---
gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c
b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c
index 1a7b0e86f8b..4b846204a65 100644
--- a/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c
+++ b/gcc/testsuite/gcc.target/loongarch/vector/lasx/lasx-xvstelm.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options "-O3 -mlasx" } */
+/* { dg-options "-O3 -mlasx -fno-vect-cost-model" } */
/* { dg-final { scan-assembler-times "xvstelm.w" 8} } */
#define LEN 256
--
2.20.1
[PATCH v1] LoongArch: Fix builtin function prototypes for LASX in doc.
gcc/ChangeLog: * doc/extend.texi:According to the documents submitted earlier, Two problems with function return types and using the actual types of parameters instead of variable names were found and fixed. --- gcc/doc/extend.texi | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 61c560a1cd3..cce6862b82b 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -18660,14 +18660,14 @@ __m256 __lasx_xvfnmsub_s (__m256, __m256, __m256); __m256d __lasx_xvfrecip_d (__m256d); __m256 __lasx_xvfrecip_s (__m256); __m256d __lasx_xvfrint_d (__m256d); -__m256i __lasx_xvfrintrm_d (__m256d); -__m256i __lasx_xvfrintrm_s (__m256); -__m256i __lasx_xvfrintrne_d (__m256d); -__m256i __lasx_xvfrintrne_s (__m256); -__m256i __lasx_xvfrintrp_d (__m256d); -__m256i __lasx_xvfrintrp_s (__m256); -__m256i __lasx_xvfrintrz_d (__m256d); -__m256i __lasx_xvfrintrz_s (__m256); +__m256d __lasx_xvfrintrm_d (__m256d); +__m256 __lasx_xvfrintrm_s (__m256); +__m256d __lasx_xvfrintrne_d (__m256d); +__m256 __lasx_xvfrintrne_s (__m256); +__m256d __lasx_xvfrintrp_d (__m256d); +__m256 __lasx_xvfrintrp_s (__m256); +__m256d __lasx_xvfrintrz_d (__m256d); +__m256 __lasx_xvfrintrz_s (__m256); __m256 __lasx_xvfrint_s (__m256); __m256d __lasx_xvfrsqrt_d (__m256d); __m256 __lasx_xvfrsqrt_s (__m256); @@ -19134,10 +19134,10 @@ __m256i __lasx_xvssub_hu (__m256i, __m256i); __m256i __lasx_xvssub_w (__m256i, __m256i); __m256i __lasx_xvssub_wu (__m256i, __m256i); void __lasx_xvst (__m256i, void *, imm_n2048_2047); -void __lasx_xvstelm_b (__m256i, void *, imm_n128_127, idx); -void __lasx_xvstelm_d (__m256i, void *, imm_n128_127, idx); -void __lasx_xvstelm_h (__m256i, void *, imm_n128_127, idx); -void __lasx_xvstelm_w (__m256i, void *, imm_n128_127, idx); +void __lasx_xvstelm_b (__m256i, void *, imm_n128_127, imm0_31); +void __lasx_xvstelm_d (__m256i, void *, imm_n128_127, imm0_3); +void __lasx_xvstelm_h (__m256i, void *, imm_n128_127, imm0_15); +void __lasx_xvstelm_w (__m256i, void *, imm_n128_127, imm0_7); void __lasx_xvstx (__m256i, void *, long int); __m256i __lasx_xvsub_b (__m256i, __m256i); __m256i __lasx_xvsub_d (__m256i, __m256i); -- 2.20.1
Re: Fwd: [PATCH v2] extend.texi: Fix typos in LSX intrinsics
在 2023-12-14四的 20:27 +0800，chenglulu写道： > > > > > > > > 转发的消息 > > > > 主题: > [PATCH v2] extend.texi: Fix typos in LSX intrinsics > > > 日期: > Wed, 13 Dec 2023 23:26:01 +0800 > > > 发件人: > Jiajie Chen > > > 收件人: > gcc-patches@gcc.gnu.org > > > 抄送: > chengl...@loongson.cn, xucheng...@loongson.cn, Jiajie > Chen > > > > > > > > Several typos have been found and fixed: missing semicolons, > using > > variable name instead of type, duplicate functions and wrong > types. > > > > gcc/ChangeLog: > > > > * doc/extend.texi(__lsx_vabsd_di): remove extra `i' in name. > > (__lsx_vfrintrm_d, __lsx_vfrintrm_s, __lsx_vfrintrne_d, > > __lsx_vfrintrne_s, __lsx_vfrintrp_d, __lsx_vfrintrp_s, > __lsx_vfrintrz_d, > > __lsx_vfrintrz_s): fix return types. > > (__lsx_vld, __lsx_vldi, __lsx_vldrepl_b, __lsx_vldrepl_d, > > __lsx_vldrepl_h, __lsx_vldrepl_w, __lsx_vmaxi_b, __lsx_vmaxi_d, > > __lsx_vmaxi_h, __lsx_vmaxi_w, __lsx_vmini_b, __lsx_vmini_d, > > __lsx_vmini_h, __lsx_vmini_w, __lsx_vsrani_d_q, > __lsx_vsrarni_d_q, > > __lsx_vsrlni_d_q, __lsx_vsrlrni_d_q, __lsx_vssrani_d_q, > > __lsx_vssrarni_d_q, __lsx_vssrarni_du_q, __lsx_vssrlni_d_q, > > __lsx_vssrlrni_du_q, __lsx_vst, __lsx_vstx, __lsx_vssrani_du_q, > > __lsx_vssrlni_du_q, __lsx_vssrlrni_d_q): add missing semicolon. > > (__lsx_vpickve2gr_bu, __lsx_vpickve2gr_hu): fix typo in return > > type. > > (__lsx_vstelm_b, __lsx_vstelm_d, __lsx_vstelm_h, > > __lsx_vstelm_w): use imm type for the last argument. > > (__lsx_vsigncov_b, __lsx_vsigncov_h, __lsx_vsigncov_w, > > __lsx_vsigncov_d): remove duplicate definitions. > > --- > > gcc/doc/extend.texi | 90 > ++--- > > 1 file changed, 43 insertions(+), 47 deletions(-) > > > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > > index f0c789f6cb4..ba1317c3510 100644 > > --- a/gcc/doc/extend.texi > > +++ b/gcc/doc/extend.texi > > @@ -17563,7 +17563,7 @@ int __lsx_bz_v (__m128i); > > int __lsx_bz_w (__m128i); > > __m128i __lsx_vabsd_b (__m128i, __m128i); > > __m128i __lsx_vabsd_bu (__m128i, __m128i); > > -__m128i __lsx_vabsd_di (__m128i, __m128i); > > +__m128i __lsx_vabsd_d (__m128i, __m128i); > > __m128i __lsx_vabsd_du (__m128i, __m128i); > > __m128i __lsx_vabsd_h (__m128i, __m128i); > > __m128i __lsx_vabsd_hu (__m128i, __m128i); > > @@ -17769,14 +17769,14 @@ __m128 __lsx_vfnmsub_s (__m128, > __m128, > __m128); > > __m128d __lsx_vfrecip_d (__m128d); > > __m128 __lsx_vfrecip_s (__m128); > > __m128d __lsx_vfrint_d (__m128d); > > -__m128i __lsx_vfrintrm_d (__m128d); > > -__m128i __lsx_vfrintrm_s (__m128); > > -__m128i __lsx_vfrintrne_d (__m128d); > > -__m128i __lsx_vfrintrne_s (__m128); > > -__m128i __lsx_vfrintrp_d (__m128d); > > -__m128i __lsx_vfrintrp_s (__m128); > > -__m128i __lsx_vfrintrz_d (__m128d); > > -__m128i __lsx_vfrintrz_s (__m128); > > +__m128d __lsx_vfrintrm_d (__m128d); > > +__m128 __lsx_vfrintrm_s (__m128); > > +__m128d __lsx_vfrintrne_d (__m128d); > > +__m128 __lsx_vfrintrne_s (__m128); > > +__m128d __lsx_vfrintrp_d (__m128d); > > +__m128 __lsx_vfrintrp_s (__m128); > > +__m128d __lsx_vfrintrz_d (__m128d); > > +__m128 __lsx_vfrintrz_s (__m128); > > __m128 __lsx_vfrint_s (__m128); > > __m128d __lsx_vfrsqrt_d (__m128d); > > __m128 __lsx_vfrsqrt_s (__m128); > > @@ -17845,12 +17845,12 @@ __m128i __lsx_vinsgr2vr_b (__m128i, > int, > imm0_15); > > __m128i __lsx_vinsgr2vr_d (__m128i, long int, imm0_1); > > __m128i __lsx_vinsgr2vr_h (__m128i, int, imm0_7); > > __m128i __lsx_vinsgr2vr_w (__m128i, int, imm0_3); > > -__m128i __lsx_vld (void *, imm_n2048_2047) > > -__m128i __lsx_vldi (imm_n1024_1023) > > -__m128i __lsx_vldrepl_b (void *, imm_n2048_2047) > > -__m128i __lsx_vldrepl_d (void *, imm_n256_255) > > -__m128i __lsx_vldrepl_h (void *, imm_n1024_1023) > > -__m128i __lsx_vldrepl_w (void *, imm_n512_511) > > +__m128i __lsx_vld (void *, imm_n2048_2047); > > +__m128i __lsx_vldi (imm_n1024_1023); > > +__m128i __lsx_vldrepl_b (void *, imm_n2048_2047); > > +__m128i __lsx_vldrepl_d (void *, imm_n256_255); > > +__m128i __lsx_vldrepl_h (void *, imm_n1024_1023); > > +__m128i __lsx_vld
[PATCH v2] LoongArch: Modify the check type of the vector builtin function.
On LoongArch architecture, using the latest gcc14 in regression test,
it is found that the vector test cases in vector directory appear FAIL
entries with unmatched pointer types. In order to solve this kind of
problem, the type of the variable in the check result is modified with
the parameter type defined in the vector builtin function.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/simd_correctness_check.h:The variable
types in the check results are modified in conjunction with the
parameter types defined in the vector builtin function.
---
v1->v2:
If an error occurs, output the data in hexadecimal format, and fill the
high part of the result with 0.
---
.../loongarch/vector/simd_correctness_check.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
index eb7fbd59cc7..551340bd51f 100644
--- a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
+++ b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
@@ -8,11 +8,12 @@
int fail = 0; \
for (size_t i = 0; i < sizeof (res) / sizeof (res[0]); ++i) \
{ \
- long *temp_ref = &ref[i], *temp_res = &res[i]; \
+ long long *temp_ref = (long long *)&ref[i], \
+ *temp_res = (long long *)&res[i]; \
if (abs (*temp_ref - *temp_res) > 0)\
{ \
printf (" error: %s at line %ld , expected " #ref \
- "[%ld]:0x%lx, got: 0x%lx\n",\
+ "[%ld]:0x%016lx, got: 0x%016lx\n", \
__FILE__, line, i, *temp_ref, *temp_res); \
fail = 1; \
} \
@@ -28,11 +29,11 @@
int fail = 0; \
for (size_t i = 0; i < sizeof (res) / sizeof (res[0]); ++i) \
{ \
- int *temp_ref = &ref[i], *temp_res = &res[i]; \
+ int *temp_ref = (int *)&ref[i], *temp_res = (int *)&res[i]; \
if (abs (*temp_ref - *temp_res) > 0)\
{ \
printf (" error: %s at line %ld , expected " #ref \
- "[%ld]:0x%x, got: 0x%x\n", \
+ "[%ld]:0x%08x, got: 0x%08x\n", \
__FILE__, line, i, *temp_ref, *temp_res); \
fail = 1; \
} \
@@ -47,8 +48,8 @@
{ \
if (ref != res) \
{ \
- printf (" error: %s at line %ld , expected %d, got %d\n", __FILE__, \
- line, ref, res);\
+ printf (" error: %s at line %ld , expected 0x:%016x", \
+ "got 0x:%016x\n", __FILE__, line, ref, res);\
} \
} \
while (0)
--
2.20.1
Re: [PATCH v1] LoongArch: Modify the check type of the vector builtin function.
在 2023-12-05二的 20:44 +0800，Xi Ruoyao写道：
> On Tue, 2023-12-05 at 17:21 +0800, chenxiaolong wrote:
> > According to your suggestion, the check of the built-in function
> > was modifiedin the simd_correctness_check.h file, and the types of
> > the actual parameters
> > of the built-in function were inconsistent with those of the formal
> > parameters.
> > The problems with the GCC regression test are as follows:
> >
> > ...
> > note: expected 'const void *' but argument is of type '__m128i'
> > error: incompatible type for argument 3 of 'ASSERTEQ_64'
> > ...
> >
> > The reason is that the types used in __m{128i,128,128d} are defined
> > in
> > the vector header file (lsxintrin.h or lasxintrin.h), and their
> > basic
> > types do not match the parameter types corresponding to the
> > functions.
>
> Ouch. I forgot that we are passing vectors themselves to
> ASSERTEQ_64,
> not the pointers.
>
> Now I come up with this:
>
> #include
> #include
> #include
>
> static inline void
> dump (const void *_ptr, int size, const char *name)
> {
> const char *ptr = (const char *)_ptr;
>
> printf("%s:", name);
>
> for (int i = 0; i < size; i++)
> printf(" %02hhx", ptr[i]);
>
> putchar('\n');
> }
>
> template
> static inline void
> assert_eq (const U &res, const V &ref, int line)
> {
> static_assert(sizeof (res) == sizeof (ref));
> if (!memcmp (&res, &ref, sizeof(ref)))
> return;
>
> dump (res, sizeof (res), "res");
> dump (ref, sizeof (ref), "ref");
> }
>
> int main()
> {
> float x[4] = {};
> int y[4] = {};
> assert_eq(x, y, __LINE__);
> }
>
> This is C++, not C. But IMO we can port the tests to C++ anyway.
>
Following your idea, I tried to change C into C++ code. The problem is
that the tests cases of LoongArch architecture are written in the style
of C language, and the code changed to C++ involves more problems and
is not easy to completely modify. So it's best to keep the C language
style.
Re: [PATCH v1] LoongArch: Modify the check type of the vector builtin function.
在 2023-12-04一的 20:38 +0800，Xi Ruoyao写道：
> On Mon, 2023-12-04 at 20:31 +0800, Xi Ruoyao wrote:
> > On Mon, 2023-12-04 at 20:14 +0800, chenxiaolong wrote:
> > > On LoongArch architecture, using the latest gcc14 in regression
> > > test,
> > > it is found that the vector test cases in vector directory appear
> > > FAIL
> > > entries with unmatched pointer types. In order to solve this kind
> > > of
> > > problem, the type of the variable in the check result is modified
> > > with
> > > the parameter type defined in the vector builtin function.
> >
> > IMO we should write something more readable:
> >
> > static inline
> > void ASSERTEQ_64 (int line, const void *_ref, const void *_res)
> > {
> > if (memcmp (_ref, _res, 16) == 0)
> > return;
> >
> > const char *ref = (const char *)_ref;
> > const char *res = (const char *)_res;
> >
> > printf ("error %s:%d: result mismatch\n", __FILE__, line);
> >
> > printf ("ref:");
> > for (int i = 0; i < 16; i++)
> > printf (" %02x", ref[i]);
>
> Sorry, should be " %02hhx" here.
>
> > printf ("\nres:");
> > for (int i = 0; i < 16; i++)
> > printf (" %02x", res[i]);
>
> Likewise.
>
> > putchar ('\n');
> > abort ();
> > }
According to your suggestion, the check of the built-in function was modifiedin
the simd_correctness_check.h file, and the types of the actual parameters
of the built-in function were inconsistent with those of the formal parameters.
The problems with the GCC regression test are as follows:
...
note: expected 'const void *' but argument is of type '__m128i'
error: incompatible type for argument 3 of 'ASSERTEQ_64'
...
The reason is that the types used in __m{128i,128,128d} are defined in
the vector header file (lsxintrin.h or lasxintrin.h), and their basic
types do not match the parameter types corresponding to the functions.
[PATCH v2] LoongArch: Add asm modifiers to the LSX and LASX directives in the doc.
gcc/ChangeLog:
* doc/extend.texi:Add modifiers to the vector of asm in the doc.
* doc/md.texi:Refine the description of the modifier 'f' in the doc.
---
gcc/doc/extend.texi | 47 +
gcc/doc/md.texi | 2 +-
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 32ae15e1d5b..d87a079704c 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -11820,10 +11820,57 @@ The list below describes the supported modifiers and
their effects for LoongArch
@item @code{d} @tab Same as @code{c}.
@item @code{i} @tab Print the character ''@code{i}'' if the operand is not a
register.
@item @code{m} @tab Same as @code{c}, but the printed value is @code{operand -
1}.
+@item @code{u} @tab Print a LASX register.
+@item @code{w} @tab Print a LSX register.
@item @code{X} @tab Print a constant integer operand in hexadecimal.
@item @code{z} @tab Print the operand in its unmodified form, followed by a
comma.
@end multitable
+References to input and output operands in the assembler template of extended
+asm statements can use modifiers to affect the way the operands are formatted
+in the code output to the assembler. For example, the following code uses the
+'w' modifier for LoongArch:
+
+@example
+test-asm.c:
+
+#include
+
+__m128i foo (void)
+@{
+__m128i a,b,c;
+__asm__ ("vadd.d %w0,%w1,%w2\n\t"
+ :"=f" (c)
+ :"f" (a),"f" (b));
+
+return c;
+@}
+
+@end example
+
+@noindent
+The compile command for the test case is as follows:
+
+@example
+gcc test-asm.c -mlsx -S -o test-asm.s
+@end example
+
+@noindent
+The assembly statement produces the following assembly code:
+
+@example
+vadd.d $vr0,$vr0,$vr1
+@end example
+
+This is a 128-bit vector addition instruction, @code{c} (referred to in the
+template string as %0) is the output, and @code{a} (%1) and @code{b} (%2) are
+the inputs. @code{__m128i} is a vector data type defined in the file
+@code{lsxintrin.h} (@xref{LoongArch SX Vector Intrinsics}). The symbol '=f'
+represents a constraint using a floating-point register as an output type, and
+the 'f' in the input operand represents a constraint using a floating-point
+register operand, which can refer to the definition of a constraint
+(@xref{Constraints}) in gcc.
+
@anchor{riscvOperandmodifiers}
@subsubsection RISC-V Operand Modifiers
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 536ce997f01..2274da5ff69 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -2881,7 +2881,7 @@ $r1h
@item LoongArch---@file{config/loongarch/constraints.md}
@table @code
@item f
-A floating-point register (if available).
+A floating-point or vector register (if available).
@item k
A memory operand whose address is formed by a base register and
(optionally scaled) index register.
--
2.20.1
[PATCH v1] LoongArch: Modify the check type of the vector builtin function.
On LoongArch architecture, using the latest gcc14 in regression test,
it is found that the vector test cases in vector directory appear FAIL
entries with unmatched pointer types. In order to solve this kind of
problem, the type of the variable in the check result is modified with
the parameter type defined in the vector builtin function.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/simd_correctness_check.h:The variable
types in the check results are modified in conjunction with the
parameter types defined in the vector builtin function.
---
.../gcc.target/loongarch/vector/simd_correctness_check.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
index eb7fbd59cc7..f780f6586b3 100644
--- a/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
+++ b/gcc/testsuite/gcc.target/loongarch/vector/simd_correctness_check.h
@@ -8,7 +8,8 @@
int fail = 0; \
for (size_t i = 0; i < sizeof (res) / sizeof (res[0]); ++i) \
{ \
- long *temp_ref = &ref[i], *temp_res = &res[i]; \
+ long long *temp_ref = (long long *)&ref[i], \
+ *temp_res = (long long *)&res[i]; \
if (abs (*temp_ref - *temp_res) > 0)\
{ \
printf (" error: %s at line %ld , expected " #ref \
@@ -28,7 +29,7 @@
int fail = 0; \
for (size_t i = 0; i < sizeof (res) / sizeof (res[0]); ++i) \
{ \
- int *temp_ref = &ref[i], *temp_res = &res[i]; \
+ int *temp_ref = (int *)&ref[i], *temp_res = (int *)&res[i]; \
if (abs (*temp_ref - *temp_res) > 0)\
{ \
printf (" error: %s at line %ld , expected " #ref \
--
2.20.1
[PATCH v1] LoongArch: Add modifiers for lsx and lasx.
gcc/ChangeLog:
* doc/extend.texi:Added modifiers for LoongArch architecture
lsx and lasx in the manual.
---
gcc/doc/extend.texi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 6e2f5b5a58c..d42c3ca49ef 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10582,6 +10582,31 @@ __asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit
#Offset in Base.
return old;
@end example
+In this LoongArch example, c (referred to in the template string as %0) is the
+output,and a (%1) and b (%2) are the inputs.Where the symbol "=f" refers to the
+use of a floating-point register as a constraint for the output type, and the
+"f" in the input operand refers to the use of a floating-point register
operand,
+the constraint can refer to the definition of constraints in gcc.
+
+This is a 128-bit double-byte vector addition instruction,the instruction
+modifier (w) represents the 128-bit vector instruction modification format,its
+corresponding output instructions are @code{"vadd.d $vr0,$vr0,$vr1"}.
+
+On the @code{LoongArch} architecture, the operand can only output the
+corresponding vector (SX/ASX) instruction if it uses @code{'w}' and @code{'u'}
+in the assembly instruction,with @code{'f'} as the constraint character.
+
+@example
+__m128i a,b,c;
+
+__asm__ ("vadd.d %w0,%w1,%w2\n\t"
+ :"=f" (c)
+ :"f" (a),"f" (b)
+ :"cc");
+
+return c;
+@end example
+
Operands are separated by commas. Each operand has this format:
@example
@@ -11680,6 +11705,8 @@ The list below describes the supported modifiers and
their effects for LoongArch
@item @code{m} @tab Same as @code{c}, but the printed value is @code{operand -
1}.
@item @code{X} @tab Print a constant integer operand in hexadecimal.
@item @code{z} @tab Print the operand in its unmodified form, followed by a
comma.
+@item @code{u} @tab Print a LASX register.
+@item @code{w} @tab Print a LSX register.
@end multitable
@anchor{riscvOperandmodifiers}
--
2.20.1
[PATCH v1] LoongArch: Add instructions for the use of vector functions.
gcc/ChangeLog:
* doc/extend.texi:Add instructions for SX and ASX vector functions
to GCC documentation, including definitions and usage of function
type aliases, constant types, and vector function prototypes.
---
gcc/doc/extend.texi | 1673 +++
1 file changed, 1673 insertions(+)
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 618f49b3968..470015a7488 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -15055,6 +15055,8 @@ instructions, but allow the compiler to schedule those
calls.
* BPF Built-in Functions::
* FR-V Built-in Functions::
* LoongArch Base Built-in Functions::
+* LoongArch SX Vector Intrinsics::
+* LoongArch ASX Vector Intrinsics::
* MIPS DSP Built-in Functions::
* MIPS Paired-Single Support::
* MIPS Loongson Built-in Functions::
@@ -16839,6 +16841,1677 @@ Returns the value that is currently set in the
@samp{tp} register.
void * __builtin_thread_pointer (void)
@end smallexample
+@node LoongArch SX Vector Intrinsics
+@subsection LoongArch SX Vector Intrinsics
+
+ Currently, GCC provides support for 128-bit and 256-bit vector operations on
+the LoongArch architecture. When using a 128-bit vector function, you need to
+add the header file @code{} and use the compile option
@code{-mlsx}
+to enable vectorization operations. They can be defined in C as follows:
+
+@smallexample
+typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
+typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
+typedef double __m128d __attribute__ ((__vector_size__ (16), __may_alias__));
+typedef int i32;
+typedef unsigned int u32;
+typedef long int i64;
+typedef unsigned long int u64;
+@end smallexample
+
+ @code{__m128} is an alias of type float, @code{128} bits (16 bytes) long, and
+uses the __may_alias__ attribute, which means that the defined alias can be
+accessed by the compiler. Similarly, @code{__m128i} and @code{__m128d} are
used
+in compilers as aliases for types long long and double respectively. @code{i32}
+and @code{i64} are used as aliases for signed integers, while @code{u32} and
+@code{u64} are used as aliases for unsigned integers.
+
+ Also, some built-in functions prefer or require immediate numbers as
+parameters, because the corresponding instructions accept both immediate
+numbers and register operands,or accept immediate numbers only. The immediate
+parameters are listed as follows.
+
+@smallexample
+* imm0_1, an integer literal in range 0 to 1.
+* imm0_3, an integer literal in range 0 to 3.
+* imm0_7, an integer literal in range 0 to 7.
+* imm0_15, an integer literal in range 0 to 15.
+* imm0_31, an integer literal in range 0 to 31.
+* imm0_63, an integer literal in range 0 to 63.
+* imm0_127, an integer literal in range 0 to 127.
+* imm0_255, an integer literal in range 0 to 255.
+* imm_n16_15, an integer literal in range -16 to 15.
+* imm_n128_127, an integer literal in range -128 to 127.
+* imm_n256_255, an integer literal in range -256 to 255.
+* imm_n512_511, an integer literal in range -512 to 511.
+* imm_n1024_1023, an integer literal in range -1024 to 1023.
+* imm_n2048_2047, an integer literal in range -2048 to 2047.
+@end smallexample
+
+ In the builtin function implemented on the LoongArch architecture, there are
+some special points to note, as shown below:
+
+ * For instructions with the same source and destination operand, the first
+residue of the builtin function call is used as the destination operand.
+
+ * The vector instruction "vldi vd,i13" is implemented according to whether
+the highest bit is 0 or 1,as shown in the following two cases.
+
+@smallexample
+a.When the highest digit of the immediate number (i13) is 0:
+ Different values of the 11th and 12th bits correspond to the following four
+instructions.
+ If @code{i13[11:10]} is set to 00, the @code{vrepli.b vd,s10} command is used
+to implement the function;
+ If @code{i13[11:10]} is set to 01, the @code{vrepli.h vd,s10} command is used
+to implement the function;
+ If @code{i13[11:10]} is set to 10, the @code{vrepli.w vd,s10} command is used
+to implement the function;
+ If @code{i13[11:10]} is set to 11, the @code{vrepli.d vd,s10} command is used
+to implement the function;
+
+ In the above four instructions, @code{s10} represents the signed number 10.
+
+b.When the highest digit of the immediate number (i13) is 1:
+ The compiler has not implemented the builtin function with the highest bit
+of 1.
+@end smallexample
+
+ * In order to support vseteqz instructions on the loongArch architecture, a
+number of builtin functions were added to the GCC compiler, which implement
+functions by combining two instructions.
+
+@smallexample
+ The corresponding assembly instructions for the @code{__lsx_bz_v} function
+are @code{vseteqz.v} and @code{bcnez}.
+ The corresponding assembly instructions for the @code{__lsx_bz_b} function
+are @code{vsetanyeqz.b} an
[PATCH v1] LoongArch: Implement __builtin_thread_pointer for TLS.
gcc/ChangeLog:
* config/loongarch/loongarch.md (get_thread_pointer):Adds the
instruction template corresponding to the __builtin_thread_pointer
function.
* doc/extend.texi:Add the __builtin_thread_pointer function support
description to the documentation.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/builtin_thread_pointer.c: New test.
---
gcc/config/loongarch/loongarch.md | 7 +++
gcc/doc/extend.texi| 5 +
.../gcc.target/loongarch/builtin_thread_pointer.c | 10 ++
3 files changed, 22 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/loongarch/builtin_thread_pointer.c
diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index 13473472171..4dd716e1941 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -113,6 +113,7 @@ (define_c_enum "unspecv" [
(define_constants
[(RETURN_ADDR_REGNUM 1)
+ (TP_REGNUM 2)
(T0_REGNUM 12)
(T1_REGNUM 13)
(S0_REGNUM 23)
@@ -3647,6 +3648,12 @@ (define_insn "@stack_tie"
[(set_attr "length" "0")
(set_attr "type" "ghost")])
+;; Named pattern for expanding thread pointer reference.
+(define_expand "get_thread_pointer"
+ [(set (match_operand:P 0 "register_operand" "=r")
+ (reg:P TP_REGNUM))]
+ "HAVE_AS_TLS"
+ {})
(define_split
[(match_operand 0 "small_data_pattern")]
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index bf941e6b93a..9923a18bde9 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -16749,6 +16749,11 @@ __float128 __builtin_nanq (void);
__float128 __builtin_nansq (void);
@end smallexample
+Returns the value that is currently set in the @samp{tp} register.
+@smallexample
+void * __builtin_thread_pointer (void)
+@end smallexample
+
@node MIPS DSP Built-in Functions
@subsection MIPS DSP Built-in Functions
diff --git a/gcc/testsuite/gcc.target/loongarch/builtin_thread_pointer.c
b/gcc/testsuite/gcc.target/loongarch/builtin_thread_pointer.c
new file mode 100644
index 000..541e3b143bd
--- /dev/null
+++ b/gcc/testsuite/gcc.target/loongarch/builtin_thread_pointer.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target tls_native } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler "or\t\\\$r4,\\\$r2,\\\$r0" } } */
+
+void *
+get_tp ()
+{
+ return __builtin_thread_pointer ();
+}
--
2.20.1
Re: [PATCH v1 4/4] LoongArch: Add tests for Loongson SX floating-point conversion instructions.
在 2023-09-06三的 18:56 +0800，Xi Ruoyao写道： > On Wed, 2023-09-06 at 18:45 +0800, Xiaolong Chen wrote: > > + *((int*)& __m128_op0[3]) = 0x004200a0; > > + *((int*)& __m128_op0[2]) = 0x; > > + *((int*)& __m128_op0[1]) = 0x004200a0; > > + *((int*)& __m128_op0[0]) = 0x0021; > > These are aliasing rule violation and they will suddenly blow up when > GCC optimizer starts to optimize more aggressively based on the > aliasing > rule. > > Try not to use these (you can write a helper function to memcpy() > into a > __m128). Or use -fno-strict-alising in dg-options. > Okay, thanks for the tip. After carefully reading the gcc manual, a new addition -fno-strict-aliasing in dg-options is added. Thanks.
[PATCH v6] LoongArch:Implement 128-bit floating point functions in gcc.
Brief version history of patch set:
v1 -> v2:
According to the GNU code specification, adjust the format of the
function implementation with "q" as the suffix function.
v2 - >v3:
1.On the LoongArch architecture, refer to the functionality of 64-bit
functions and modify the underlying implementation of __builtin_{nanq, nansq}
functions in libgcc.
2.Modify the function's instruction template to use some instructions such
as "bstrins.d" to implement the 128-bit __builtin_{fabsq, copysignq} function
instead of calling libgcc library support, so as to better play the machine's
performance.
v3 -> v4:
1.The above v1,v2, and v3 all implement 128-bit floating-point functions
with "q" as the suffix, but it is an older implementation. The v4 version
completely abandoned the old implementation by associating the 128-bit
floating-point function with the "q" suffix with the "f128" function that
already existed in GCC.
2.Modify the code so that both "__float128" and "_Float128" function types
can be supported in compiler gcc.
3.Associating a function with the suffix "q" to the "f128" function allows
two different forms of the function to produce the same effect, For example,
__builtin_{huge_{valq/valf128},{infq/inff128},{nanq/nanf128},{nansq/nansf128},
{fabsq/fabsf128}}.
4.For the _builtin_copysignq function, do not call the new "f128"
implementation, but use the "bstrins" and other instructions in the machine
description file to implement the function function, the result is that the
number of assembly instructions can be reduced and the function optimization
to achieve the optimal effect.
v4 -> v5:
Removed the v4 implementation of the __builtin_fabsf128() function added
to LoongArch.md.
v5 -> v6:
1.Modify the test cases in the math-float-128.c file.
2.Removed the v5 implementation of the __builtin_copysignf128() function
added to LoongArch.md.
During implementation, float128_type_node is bound with the type "__float128"
so that the compiler can correctly identify the type of the function. The
"q" suffix is associated with the "f128" function, which makes GCC more
flexible to support different user input cases, implementing functions such
as __builtin_{huge_valq, infq, fabsq, copysignq, nanq, nansq}.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc (loongarch_init_builtins):
Associate the __float128 type to float128_type_node so that it can
be recognized by the compiler.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins):
Add the flag "FLOAT128_TYPE" to gcc and associate a function
with the suffix "q" to "f128".
* doc/extend.texi:Added support for 128-bit floating-point functions on
the LoongArch architecture.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/math-float-128.c: New test.
---
gcc/config/loongarch/loongarch-builtins.cc| 5 ++
gcc/config/loongarch/loongarch-c.cc | 11 +++
gcc/doc/extend.texi | 20 -
.../gcc.target/loongarch/math-float-128.c | 81 +++
4 files changed, 114 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/math-float-128.c
diff --git a/gcc/config/loongarch/loongarch-builtins.cc
b/gcc/config/loongarch/loongarch-builtins.cc
index b929f224dfa..58b612bf445 100644
--- a/gcc/config/loongarch/loongarch-builtins.cc
+++ b/gcc/config/loongarch/loongarch-builtins.cc
@@ -256,6 +256,11 @@ loongarch_init_builtins (void)
unsigned int i;
tree type;
+ /* Register the type float128_type_node as a built-in type and
+ give it an alias "__float128". */
+ (*lang_hooks.types.register_builtin_type) (float128_type_node,
+ "__float128");
+
/* Iterate through all of the bdesc arrays, initializing all of the
builtin functions. */
for (i = 0; i < ARRAY_SIZE (loongarch_builtins); i++)
diff --git a/gcc/config/loongarch/loongarch-c.cc
b/gcc/config/loongarch/loongarch-c.cc
index 67911b78f28..6ffbf748316 100644
--- a/gcc/config/loongarch/loongarch-c.cc
+++ b/gcc/config/loongarch/loongarch-c.cc
@@ -99,6 +99,17 @@ loongarch_cpu_cpp_builtins (cpp_reader *pfile)
else
builtin_define ("__loongarch_frlen=0");
+ /* Add support for FLOAT128_TYPE on the LoongArch architecture. */
+ builtin_define ("__FLOAT128_TYPE__");
+
+ /* Map the old _Float128 'q' builtins into the new 'f128' builtins. */
+ 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");
+
/* Native Data Sizes. */
builtin_define_with_int_value ("_LOONGARCH_SZINT", INT_TYPE_SIZE);
builtin_define_with_int_value ("_LOONGARCH_SZLONG", LONG_TYPE_SIZE
Re: [PATCH v5] LoongArch:Implement 128-bit floating point functions in gcc.
在 2023-08-31四的 15:57 +0800，Xi Ruoyao写道：
> On Thu, 2023-08-31 at 15:02 +0800, chenxiaolong wrote:
> > +;; Implement __builtin_copysignf128 function.
> > +
> > +(define_insn_and_split "copysigntf3"
> > + [(set (match_operand:TF 0 "register_operand" "=&r")
> > + (unspec:TF [(match_operand:TF 1 "register_operand" "r")
> > + (match_operand:TF 2 "register_operand" "r")]
> > + UNSPEC_COPYSIGNF128))]
> > + "TARGET_64BIT"
> > + "#"
> > + "reload_completed"
> > + [(const_int 0)]
> > +{
> > + rtx op0_lo = gen_rtx_REG (DImode,REGNO (operands[0]) + 0);
> > + rtx op0_hi = gen_rtx_REG (DImode,REGNO (operands[0]) + 1);
> > + rtx op1_lo = gen_rtx_REG (DImode,REGNO (operands[1]) + 0);
> > + rtx op1_hi = gen_rtx_REG (DImode,REGNO (operands[1]) + 1);
> > + rtx op2_hi = gen_rtx_REG (DImode,REGNO (operands[2]) + 1);
> > +
> > + if (REGNO (operands[1]) == REGNO (operands[2]))
> > +{
> > + loongarch_emit_move (operands[0], operands[1]);
> > + DONE;
> > +}
> > + else
> > +{
> > + loongarch_emit_move (op0_hi, op2_hi);
> > + loongarch_emit_move (op0_lo, op1_lo);
> > + emit_insn (gen_insvdi (op0_hi, GEN_INT (63), GEN_INT (0),
> > op1_hi));
> > + DONE;
> > +}
> > +})
>
> Please remove this part too, for now. I'm trying to figure out a
> more
> generic fix, and if I fail we can add this part later.
>
Ok, then wait for your modified message, and then I will submit the
newly modified code according to the content.
[PATCH v5] LoongArch:Implement 128-bit floating point functions in gcc.
Brief version history of patch set:
v1 -> v2:
According to the GNU code specification, adjust the format of the
function implementation with "q" as the suffix function.
v2 - >v3:
1.On the LoongArch architecture, refer to the functionality of 64-bit
functions
and modify the underlying implementation of __builtin_{nanq,nansq} functions
in libgcc.
2.Modify the function's instruction template to use some instructions such as
"bstrins.d" to implement the 128-bit __builtin_{fabsq,copysignq} function
instead of calling libgcc library support, so as to better play the machine's
performance.
v3 -> v4:
1.The above v1,v2, and v3 all implement 128-bit floating-point functions
with "q" as the suffix, but it is an older implementation. The v4 version
completely abandoned the old implementation by associating the 128-bit
floating-point function with the "q" suffix with the "f128" function that
already existed in GCC.
2.Modify the code so that both "__float128" and "_Float128" function types
can be supported in compiler gcc.
3.Associating a function with the suffix "q" to the "f128" function allows
two different forms of the function to produce the same effect, For example,
__builtin_{huge_{valq,valf128},{infq/inff128},{nanq/nanf128},{nansq/nansf128},
{fabsq/fabsf128}}.
4.For the _builtin_copysignq function, do not call the new "f128"
implementation, but use the "bstrins" and other instructions in the machine
description file to implement the function function, the result is that the
number of assembly instructions can be reduced and the function optimization
to achieve the optimal effect.
v4 -> v5:
Removed the v4 implementation of the __builtin_fabsf128() function added
to LoongArch.md.
During implementation, float128_type_node is bound with the type "__float128"
so that the compiler can correctly identify the type of the function. The
"q" suffix is associated with the "f128" function, which makes GCC more
flexible to support different user input cases, implementing functions such
as __builtin_{huge_valq,infq, fabsq, copysignq, nanq,nansq}.At the same time,
the __builtin_{copysign{q/f128}} functions are optimized by using "bstrins"
and other instructions on LoongArch architecture to better play the
optimization performance of the compiler.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc (loongarch_init_builtins):
Associate the __float128 type to float128_type_node so that it can
be recognized by the compiler.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins):
Add the flag "FLOAT128_TYPE" to gcc and associate a function
with the suffix "q" to "f128".
* config/loongarch/loongarch.md (copysigntf3):Modify the instruction
template to implement the __builtin_{copysignf128} function.
* doc/extend.texi:Added support for 128-bit floating-point functions on
the LoongArch architecture.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/math-float-128.c: New test.
---
gcc/config/loongarch/loongarch-builtins.cc| 5 +
gcc/config/loongarch/loongarch-c.cc | 11 ++
gcc/config/loongarch/loongarch.md | 33 +
gcc/doc/extend.texi | 20 ++-
.../gcc.target/loongarch/math-float-128.c | 115 ++
5 files changed, 181 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/math-float-128.c
diff --git a/gcc/config/loongarch/loongarch-builtins.cc
b/gcc/config/loongarch/loongarch-builtins.cc
index b929f224dfa..58b612bf445 100644
--- a/gcc/config/loongarch/loongarch-builtins.cc
+++ b/gcc/config/loongarch/loongarch-builtins.cc
@@ -256,6 +256,11 @@ loongarch_init_builtins (void)
unsigned int i;
tree type;
+ /* Register the type float128_type_node as a built-in type and
+ give it an alias "__float128". */
+ (*lang_hooks.types.register_builtin_type) (float128_type_node,
+ "__float128");
+
/* Iterate through all of the bdesc arrays, initializing all of the
builtin functions. */
for (i = 0; i < ARRAY_SIZE (loongarch_builtins); i++)
diff --git a/gcc/config/loongarch/loongarch-c.cc
b/gcc/config/loongarch/loongarch-c.cc
index 67911b78f28..6ffbf748316 100644
--- a/gcc/config/loongarch/loongarch-c.cc
+++ b/gcc/config/loongarch/loongarch-c.cc
@@ -99,6 +99,17 @@ loongarch_cpu_cpp_builtins (cpp_reader *pfile)
else
builtin_define ("__loongarch_frlen=0");
+ /* Add support for FLOAT128_TYPE on the LoongArch architecture. */
+ builtin_define ("__FLOAT128_TYPE__");
+
+ /* Map the old _Float128 'q' builtins into the new 'f128' builtins. */
+ 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");
+
[PATCH v4] LoongArch:Implement 128-bit floating point functions in gcc.
Brief version history of patch set:
v1 -> v2:
According to the GNU code specification, adjust the format of the
function implementation with "q" as the suffix function.
v2 - >v3:
1.On the LoongArch architecture, refer to the functionality of 64-bit
functions
and modify the underlying implementation of __builtin_{nanq,nansq} functions
in libgcc.
2.Modify the function's instruction template to use some instructions such as
"bstrins.d" to implement the 128-bit __builtin_{fabsq,copysignq} function
instead of calling libgcc library support, so as to better play the machine's
performance.
v3 -> v4:
1.The above v1,v2, and v3 all implement 128-bit floating-point functions
with "q" as the suffix, but it is an older implementation. The v4 version
completely abandoned the old implementation by associating the 128-bit
floating-point function with the "q" suffix with the "f128" function that
already existed in GCC.
2.Modify the code so that both "__float128" and "_Float128" function types
can be supported in compiler gcc.
3.Associating a function with the suffix "q" to the "f128" function allows
two different forms of the function to produce the same effect, For example,
__builtin_{huge_{valq,valf128},{infq/inff128},{nanq/nanf128},{nansq/nansf128}}.
4.For the _builtin_{fabsq,copysignq} function, do not call the new "f128"
implementation, but use the "bstrins" and other instructions in the machine
description file to implement the function function, the result is that the
number of assembly instructions can be reduced and the function optimization
to achieve the optimal effect.
During implementation, float128_type_node is bound with the type "__float128"
so that the compiler can correctly identify the type of the function. The
"q" suffix is associated with the "f128" function, which makes GCC more
flexible to support different user input cases, implementing functions such
as __builtin_{huge_valq infq, fabsq, copysignq, nanq,nansq}.At the same time,
the __builtin_{copysign{q/f128},fabs{q/f128}} functions are optimized by
using "bstrins" and other instructions on LoongArch architecture to better
play the optimization performance of the compiler.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc (loongarch_init_builtins):
Associate the __float128 type to float128_type_node so that it can
be recognized by the compiler.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins):
Add the flag "FLOAT128_TYPE" to gcc and associate a function
with the suffix "q" to "f128".
* config/loongarch/loongarch.md (abstf2):Modify the instruction
template to implement the __builtin_{copysignf128/fabsf128} function.
(abstf_local):Ditto.
(copysigntf3):Implement the built-in function __builtin_copysignf128().
* doc/extend.texi:Added support for 128-bit floating-point functions on
the LoongArch architecture.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/math-float-128.c: New test.
---
gcc/config/loongarch/loongarch-builtins.cc| 5 +
gcc/config/loongarch/loongarch-c.cc | 11 ++
gcc/config/loongarch/loongarch.md | 54
gcc/doc/extend.texi | 20 ++-
.../gcc.target/loongarch/math-float-128.c | 115 ++
5 files changed, 202 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/loongarch/math-float-128.c
diff --git a/gcc/config/loongarch/loongarch-builtins.cc
b/gcc/config/loongarch/loongarch-builtins.cc
index b929f224dfa..58b612bf445 100644
--- a/gcc/config/loongarch/loongarch-builtins.cc
+++ b/gcc/config/loongarch/loongarch-builtins.cc
@@ -256,6 +256,11 @@ loongarch_init_builtins (void)
unsigned int i;
tree type;
+ /* Register the type float128_type_node as a built-in type and
+ give it an alias "__float128". */
+ (*lang_hooks.types.register_builtin_type) (float128_type_node,
+ "__float128");
+
/* Iterate through all of the bdesc arrays, initializing all of the
builtin functions. */
for (i = 0; i < ARRAY_SIZE (loongarch_builtins); i++)
diff --git a/gcc/config/loongarch/loongarch-c.cc
b/gcc/config/loongarch/loongarch-c.cc
index 67911b78f28..6ffbf748316 100644
--- a/gcc/config/loongarch/loongarch-c.cc
+++ b/gcc/config/loongarch/loongarch-c.cc
@@ -99,6 +99,17 @@ loongarch_cpu_cpp_builtins (cpp_reader *pfile)
else
builtin_define ("__loongarch_frlen=0");
+ /* Add support for FLOAT128_TYPE on the LoongArch architecture. */
+ builtin_define ("__FLOAT128_TYPE__");
+
+ /* Map the old _Float128 'q' builtins into the new 'f128' builtins. */
+ 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
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_d
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.
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 shou
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.
>
[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),
@@
[PATCH v2] 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}.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc (DEF_LARCH_FTYPE):
(MATHQ_NUMS=):Counts the number of builtin functions with the
suffix "q".
(enum loongarch_builtin_type):Add the type of the function.
(FLOAT_BUILTIN_HIQ):
(FLOAT_BUILTIN_NNFCQ):
(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.
libgcc/ChangeLog:
* config/loongarch/t-softfp-tf:
* config/loongarch/tf-signs.c: New file.
---
gcc/config/loongarch/loongarch-builtins.cc | 158 -
gcc/config/loongarch/loongarch-protos.h| 2 +
gcc/config/loongarch/loongarch.cc | 14 ++
gcc/config/loongarch/loongarch.md | 25
libgcc/config/loongarch/t-softfp-tf| 3 +
libgcc/config/loongarch/tf-signs.c | 99 +
6 files changed, 299 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..6e32f86fc52 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,12 @@ 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,
+
+ /* Define the type of the __builtin_{nanq,nansq,fabsq,copysignq} function.
*/
+ LARCH_BUILTIN_NNFCQ_DIRECT
+
};
/* Declare an availability predicate for built-in functions that require
@@ -136,6 +153,18 @@ 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 {nanq,nansq,fabsq,copysignq}.*/
+#define FLOAT_BUILTIN_NNFCQ(INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ ## INSN, \
+"__builtin_" #INSN, LARCH_BUILTIN_NNFCQ_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),
@@ -183,6 +212,14 @@ static const struct loongarch_builtin_description
loongarch_builtins[] = {
DIRECT_NO_TARGET_BUILTIN (asrtgt_d, LARCH_VOID_FTYPE_DI_DI, default),
DIRECT_NO_TARGET_BUILTIN (syscall, LARCH_VOID_FTYPE_USI, default),
DIRECT_NO_TARGET_BUILTIN (break, LARCH_VOID_FTYPE_USI, default),
+
+ FLOAT_BUILTIN_HIQ (huge_valq, LARCH_BUILTIN_HUGE_VALQ),
+ FLOAT_BUILTIN_HIQ (infq, LARCH_BUILTIN_INFQ),
+ FLOAT_BUILTIN_NNFCQ (fabsq, LARCH_BUILTIN_FABSQ),
+ FLOAT_BUILTIN_NNFCQ (nanq, LARCH_BUILTIN_NANQ),
+ FLOAT_BUILTIN_NNFCQ (nansq, LARCH_BUILTIN_NANSQ),
+ FLOAT_BUILTIN_NNFCQ (copysignq, LARCH
[PATCH v2] 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}.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc (DEF_LARCH_FTYPE):
(MATHQ_NUMS=):Counts the number of builtin functions with the
suffix "q".
(enum loongarch_builtin_type):Add the type of the function.
(FLOAT_BUILTIN_HIQ):
(FLOAT_BUILTIN_NNFCQ):
(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.
libgcc/ChangeLog:
* config/loongarch/t-softfp-tf:
* config/loongarch/tf-signs.c: New file.
---
gcc/config/loongarch/loongarch-builtins.cc | 158 -
gcc/config/loongarch/loongarch-protos.h| 2 +
gcc/config/loongarch/loongarch.cc | 14 ++
gcc/config/loongarch/loongarch.md | 25
libgcc/config/loongarch/t-softfp-tf| 3 +
libgcc/config/loongarch/tf-signs.c | 99 +
6 files changed, 299 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..6e32f86fc52 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,12 @@ 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,
+
+ /* Define the type of the __builtin_{nanq,nansq,fabsq,copysignq} function.
*/
+ LARCH_BUILTIN_NNFCQ_DIRECT
+
};
/* Declare an availability predicate for built-in functions that require
@@ -136,6 +153,18 @@ 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 {nanq,nansq,fabsq,copysignq}.*/
+#define FLOAT_BUILTIN_NNFCQ(INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ ## INSN, \
+"__builtin_" #INSN, LARCH_BUILTIN_NNFCQ_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),
@@ -183,6 +212,14 @@ static const struct loongarch_builtin_description
loongarch_builtins[] = {
DIRECT_NO_TARGET_BUILTIN (asrtgt_d, LARCH_VOID_FTYPE_DI_DI, default),
DIRECT_NO_TARGET_BUILTIN (syscall, LARCH_VOID_FTYPE_USI, default),
DIRECT_NO_TARGET_BUILTIN (break, LARCH_VOID_FTYPE_USI, default),
+
+ FLOAT_BUILTIN_HIQ (huge_valq, LARCH_BUILTIN_HUGE_VALQ),
+ FLOAT_BUILTIN_HIQ (infq, LARCH_BUILTIN_INFQ),
+ FLOAT_BUILTIN_NNFCQ (fabsq, LARCH_BUILTIN_FABSQ),
+ FLOAT_BUILTIN_NNFCQ (nanq, LARCH_BUILTIN_NANQ),
+ FLOAT_BUILTIN_NNFCQ (nansq, LARCH_BUILTIN_NANSQ),
+ FLOAT_BUILTIN_NNFCQ (copysignq, LARCH
[PATCH v1] LoongArch:Implement 128-bit floating point functions in gcc.
From: Xiaolong Chen
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}.
gcc/ChangeLog:
* config/loongarch/loongarch-builtins.cc (DEF_LARCH_FTYPE):
(MATHQ_NUMS=):Add the type of the builtin(q) function.
(enum loongarch_builtin_type):Add the type of the function.
(FLOAT_BUILTIN_HUGE):
(FLOAT_BUILTIN_INFQ):
(FLOAT_BUILTIN_FABSQ):
(FLOAT_BUILTIN_COPYSIGNQ):
(FLOAT_BUILTIN_NANQ):
(FLOAT_BUILTIN_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.
libgcc/ChangeLog:
* config/loongarch/t-softfp-tf:
* config/loongarch/tf-signs.c: New file.
---
gcc/config/loongarch/loongarch-builtins.cc | 196 -
gcc/config/loongarch/loongarch-protos.h| 2 +
gcc/config/loongarch/loongarch.cc | 14 ++
gcc/config/loongarch/loongarch.md | 25 +++
libgcc/config/loongarch/t-softfp-tf| 3 +
libgcc/config/loongarch/tf-signs.c | 99 +++
6 files changed, 337 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..cb7f0e60674 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 */
+static 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
{
@@ -62,7 +73,25 @@ enum loongarch_builtin_type
/* The function corresponds directly to an .md pattern. There is no return
value and the arguments are mapped to operands 0 and above. */
LARCH_BUILTIN_DIRECT_NO_TARGET,
+
+ /*The function corresponds to an __builtin_huge_valq */
+ LARCH_BUILTIN_HUGE_DIRECT ,
+
+ /*Define the type of the __builtin_infq function */
+ LARCH_BUILTIN_INFQ_DIRECT ,
+
+ /*Define the type of the __builtin_fabsq function*/
+ LARCH_BUILTIN_FABSQ_DIRECT ,
+ /*Define the type of the __builtin_copysignq function */
+ LARCH_BUILTIN_COPYSIGNQ_DIRECT ,
+
+
+ /*Define the type of the __builtin_copysignq function */
+ LARCH_BUILTIN_NANQ_DIRECT ,
+
+ /*Define the type of the __builtin_copysignq function */
+ LARCH_BUILTIN_NANSQ_DIRECT ,
};
/* Declare an availability predicate for built-in functions that require
@@ -135,6 +164,41 @@ AVAIL_ALL (hard_float, TARGET_HARD_FLOAT_ABI)
#define DIRECT_NO_TARGET_BUILTIN(INSN, FUNCTION_TYPE, AVAIL) \
LARCH_BUILTIN (INSN, #INSN, LARCH_BUILTIN_DIRECT_NO_TARGET, \
FUNCTION_TYPE, AVAIL)
+/* Define an float to do funciton huge_valq*/
+#define FLOAT_BUILTIN_HUGE(INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ ## INSN, \
+"__builtin_" #INSN, LARCH_BUILTIN_HUGE_DIRECT,\
+FUNCTION_TYPE, loongarch_builtin_avail_default }
+
+/* Define an float to do funciton infq*/
+#define FLOAT_BUILTIN_INFQ(INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ ## INSN, \
+"__builtin_" #INSN, LARCH_BUILTIN_INFQ_DIRECT,\
+FUNCTION_TYPE, loongarch_builtin_avail_default }
+
+/* Define an float to do funciton fabsq*/
+#define FLOAT_BUILTIN_FABSQ(INSN, FUNCTION_TYPE) \
+{ CODE_FOR_ #
