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()
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 +
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
> > > D
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
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
---
在 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 Mond
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:
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/signbi
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:
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.
---
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
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.
---
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
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:
*
- 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
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.
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
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
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(+),
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
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
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
ion 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 detect
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.e
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.
---
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.
---
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
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
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
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
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
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
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
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
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.
---
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
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
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
在 2023-12-14四的 20:27 +0800，chenglulu写道：
>
>
>
>
>
>
>
> 转发的消息
>
>
>
> 主题:
> [PATCH v2] extend.texi: Fix typos in LSX intrinsics
>
>
> 日期:
> Wed, 13
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
在 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
在 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
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
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
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
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
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.
在 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
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
在 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" &
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
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
在 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-1
在 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"
g-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"
, 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
> &g
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
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
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
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
60 matches
Mail list logo
