| Message ID | 20231229040015.6275-1-chenxiaolong@loongson.cn |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] LoongArch: testsuite:Add the "-ffast-math" compilation option for the file vect-fmin-3.c. | expand |
chenxiaolong <chenxiaolong@loongson.cn> writes: > 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. This shouldn't be necessary. The test does: for (int i = 0; i < n; i += 2) { x0 = __builtin_fmin (x0, ptr[i + 0]); x1 = __builtin_fmin (x1, ptr[i + 1]); } res[0] = x0; res[1] = x1; __builtin_fmin is an FP minimum operation that corresponds directly to the fmin*3 optab (or reduc_fmin_scal_* for reductions). It is naturally associative, so doesn't need -ffast-math for that. Does LoongArch provide reduc_min_scal_* but not reduc_fmin_scal_*? If so, we probably need a new target selector for fmin/fmax reduction. Thanks, Richard > --- > 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"
On Sat, 2023-12-30 at 12:15 +0000, Richard Sandiford wrote: > This shouldn't be necessary. The test does: > > for (int i = 0; i < n; i += 2) > { > x0 = __builtin_fmin (x0, ptr[i + 0]); > x1 = __builtin_fmin (x1, ptr[i + 1]); > } > res[0] = x0; > res[1] = x1; > > __builtin_fmin is an FP minimum operation that corresponds directly to > the fmin*3 optab (or reduc_fmin_scal_* for reductions). It is naturally > associative, so doesn't need -ffast-math for that. > > Does LoongArch provide reduc_min_scal_* but not reduc_fmin_scal_*? > If so, we probably need a new target selector for fmin/fmax reduction. Let me try if the [x]vf{min,max} instructions are IEEE-conform. They've still not released the volume 2 of the instruction manual so I can only try...
On Sat, 2023-12-30 at 20:25 +0800, Xi Ruoyao wrote: > On Sat, 2023-12-30 at 12:15 +0000, Richard Sandiford wrote: > > This shouldn't be necessary. The test does: > > > > for (int i = 0; i < n; i += 2) > > { > > x0 = __builtin_fmin (x0, ptr[i + 0]); > > x1 = __builtin_fmin (x1, ptr[i + 1]); > > } > > res[0] = x0; > > res[1] = x1; > > > > __builtin_fmin is an FP minimum operation that corresponds directly to > > the fmin*3 optab (or reduc_fmin_scal_* for reductions). It is naturally > > associative, so doesn't need -ffast-math for that. > > > > Does LoongArch provide reduc_min_scal_* but not reduc_fmin_scal_*? > > If so, we probably need a new target selector for fmin/fmax reduction. > > Let me try if the [x]vf{min,max} instructions are IEEE-conform. They've > still not released the volume 2 of the instruction manual so I can only > try... They are conforming (at least on LA464). I'll make a patch to add f{min/max} and reduc_f{min/max}_scal_* for LoongArch SIMD.
在 2023/12/30 下午8:25, Xi Ruoyao 写道: > On Sat, 2023-12-30 at 12:15 +0000, Richard Sandiford wrote: >> This shouldn't be necessary. The test does: >> >> for (int i = 0; i < n; i += 2) >> { >> x0 = __builtin_fmin (x0, ptr[i + 0]); >> x1 = __builtin_fmin (x1, ptr[i + 1]); >> } >> res[0] = x0; >> res[1] = x1; >> >> __builtin_fmin is an FP minimum operation that corresponds directly to >> the fmin*3 optab (or reduc_fmin_scal_* for reductions). It is naturally >> associative, so doesn't need -ffast-math for that. >> >> Does LoongArch provide reduc_min_scal_* but not reduc_fmin_scal_*? >> If so, we probably need a new target selector for fmin/fmax reduction. > Let me try if the [x]vf{min,max} instructions are IEEE-conform. They've > still not released the volume 2 of the instruction manual so I can only > try... > These two instructions are in compliance with the ieee-754 standard.
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"
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(+)