[v1] RISC-V: Refine the testcases for cond_widen_complicate-3
Checks
| Context |
Check |
Description |
| rivoscibot/toolchain-ci-rivos-lint |
success
|
Lint passed
|
| rivoscibot/toolchain-ci-rivos-apply-patch |
success
|
Patch applied
|
| rivoscibot/toolchain-ci-rivos-build--newlib-rv64gcv-lp64d-multilib |
success
|
Build passed
|
| rivoscibot/toolchain-ci-rivos-build--linux-rv64gc_zba_zbb_zbc_zbs-lp64d-multilib |
success
|
Build passed
|
| rivoscibot/toolchain-ci-rivos-build--linux-rv64gcv-lp64d-multilib |
success
|
Build passed
|
| rivoscibot/toolchain-ci-rivos-test |
success
|
Testing passed
|
| linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gcc_build--master-arm |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gcc_check--master-arm |
success
|
Test passed
|
| linaro-tcwg-bot/tcwg_simplebootstrap_build--master-aarch64-bootstrap |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_simplebootstrap_build--master-arm-bootstrap |
success
|
Build passed
|
| linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 |
success
|
Test passed
|
Commit Message
From: Pan Li <pan2.li@intel.com>
Rearrange the test cases of cond_widen_complicate-3 by different types
into different files, instead of put all types together. Then we can
easily reduce the range when asm check fails.
The below test suites are passed locally, let's wait online CI says.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.c: Removed.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i32.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i8.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u16.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u32.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u8.c: New test.
* gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.h: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
---
.../cond/cond_widen_complicate-3-f16.c | 9 +++++
.../cond/cond_widen_complicate-3-f32.c | 9 +++++
.../cond/cond_widen_complicate-3-i16.c | 9 +++++
.../cond/cond_widen_complicate-3-i32.c | 9 +++++
.../autovec/cond/cond_widen_complicate-3-i8.c | 9 +++++
.../cond/cond_widen_complicate-3-u16.c | 9 +++++
.../cond/cond_widen_complicate-3-u32.c | 9 +++++
.../autovec/cond/cond_widen_complicate-3-u8.c | 9 +++++
.../autovec/cond/cond_widen_complicate-3.c | 36 -------------------
.../autovec/cond/cond_widen_complicate-3.h | 21 +++++++++++
10 files changed, 93 insertions(+), 36 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f16.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-f32.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i16.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i32.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-i8.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u16.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u32.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3-u8.c
delete mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.c
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/cond/cond_widen_complicate-3.h
Comments
> From: Pan Li <pan2.li@intel.com>
>
> Rearrange the test cases of cond_widen_complicate-3 by different types
> into different files, instead of put all types together. Then we can
> easily reduce the range when asm check fails.
I'm not opposed to refactoring but what's the reason for it? We have a large
number of similar tests that also include all possible types. And aren't all
the tests you touch FAILing anyway right now? (Due to the combine change...)
> I'm not opposed to refactoring but what's the reason for it? We have a large
> number of similar tests that also include all possible types. And aren't all
> the tests you touch FAILing anyway right now? (Due to the combine change...)
Yes, the cond_widen_complicate-3 need some tweak for the asm check failure.
Simply adjust the count cannot guarantee that each type has generated at least
one vw/vfw. For example, i8 doesn't generate vw but i16 generate 2 vw insn,
and the final asm check times is the same.
Thus, I refactor them into different types to meet current behavior.
Pan
-----Original Message-----
From: Robin Dapp <rdapp.gcc@gmail.com>
Sent: Wednesday, March 12, 2025 7:11 PM
To: Li, Pan2 <pan2.li@intel.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; kito.cheng@gmail.com; jeffreyalaw@gmail.com; Chen, Ken <ken.chen@intel.com>; Robin Dapp <rdapp.gcc@gmail.com>
Subject: Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3
> From: Pan Li <pan2.li@intel.com>
>
> Rearrange the test cases of cond_widen_complicate-3 by different types
> into different files, instead of put all types together. Then we can
> easily reduce the range when asm check fails.
I'm not opposed to refactoring but what's the reason for it? We have a large
number of similar tests that also include all possible types. And aren't all
the tests you touch FAILing anyway right now? (Due to the combine change...)
--
Regards
Robin
>> I'm not opposed to refactoring but what's the reason for it? We have a large
>> number of similar tests that also include all possible types. And aren't all
>> the tests you touch FAILing anyway right now? (Due to the combine change...)
>
> Yes, the cond_widen_complicate-3 need some tweak for the asm check failure.
> Simply adjust the count cannot guarantee that each type has generated at least
> one vw/vfw. For example, i8 doesn't generate vw but i16 generate 2 vw insn,
> and the final asm check times is the same.
>
> Thus, I refactor them into different types to meet current behavior.
OK.
Not that I see it as absolute necessity but I don't mind either way.
We don't just want to tweak the asm checks, though. The code is indeed
worse than before.
> OK.
Thanks Robin.
> Not that I see it as absolute necessity but I don't mind either way.
> We don't just want to tweak the asm checks, though. The code is indeed
> worse than before.
I see, will leave other similar cases like cond_widen_complicate-[4|8] as is.
And it seems no other failures from rvv.exp now.
Pan
-----Original Message-----
From: Robin Dapp <rdapp.gcc@gmail.com>
Sent: Thursday, March 13, 2025 5:48 PM
To: Li, Pan2 <pan2.li@intel.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; kito.cheng@gmail.com; jeffreyalaw@gmail.com; Chen, Ken <ken.chen@intel.com>; Robin Dapp <rdapp.gcc@gmail.com>
Subject: Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3
>> I'm not opposed to refactoring but what's the reason for it? We have a large
>> number of similar tests that also include all possible types. And aren't all
>> the tests you touch FAILing anyway right now? (Due to the combine change...)
>
> Yes, the cond_widen_complicate-3 need some tweak for the asm check failure.
> Simply adjust the count cannot guarantee that each type has generated at least
> one vw/vfw. For example, i8 doesn't generate vw but i16 generate 2 vw insn,
> and the final asm check times is the same.
>
> Thus, I refactor them into different types to meet current behavior.
OK.
Not that I see it as absolute necessity but I don't mind either way.
We don't just want to tweak the asm checks, though. The code is indeed
worse than before.
--
Regards
Robin
Hi Pan,
Richard committed combine patches that restored most of the previous behavior
so we shouldn't need the refinement any more.
AFAICT the tests should now pass in their previous state but definitely fail in
their current state. Do you want to revert this change?
Thanks.
I see, reverted. Thanks Robin for reminder.
BTW and just for open discussion, is this really a good way for such kind of tests?
Though most of the tests are similar like this but it may hide possible unexpected results up to a point.
Pan
-----Original Message-----
From: Robin Dapp <rdapp.gcc@gmail.com>
Sent: Wednesday, April 9, 2025 6:47 PM
To: Li, Pan2 <pan2.li@intel.com>; Robin Dapp <rdapp.gcc@gmail.com>; gcc-patches@gcc.gnu.org
Cc: juzhe.zhong@rivai.ai; kito.cheng@gmail.com; jeffreyalaw@gmail.com; Chen, Ken <ken.chen@intel.com>; Robin Dapp <rdapp.gcc@gmail.com>
Subject: Re: [PATCH v1] RISC-V: Refine the testcases for cond_widen_complicate-3
Hi Pan,
Richard committed combine patches that restored most of the previous behavior
so we shouldn't need the refinement any more.
AFAICT the tests should now pass in their previous state but definitely fail in
their current state. Do you want to revert this change?
Thanks.
--
Regards
Robin
> I see, reverted. Thanks Robin for reminder.
Thanks!
> BTW and just for open discussion, is this really a good way for such kind of
> tests?
> Though most of the tests are similar like this but it may hide possible
> unexpected results up to a point.
Yeah we have several flaky tests and in those cases we should try to change the
test criteria. This one here, though, I wouldn't count to them as it expects a
certain number of widening ops. Due to the combine changes (lack of 2->2
combinations I think) we couldn't achieve the result we expected and the code
was indeed slightly worse.
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv_zvfh -mabi=ilp32d -mrvv-vector-bits=scalable -ffast-math" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (float, _Float16)
+
+/* { dg-final { scan-assembler-times {\tvfwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d -mrvv-vector-bits=scalable -ffast-math" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (double, float)
+
+/* { dg-final { scan-assembler-times {\tvfwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d -mrvv-vector-bits=scalable" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (int32_t, int16_t)
+
+/* { dg-final { scan-assembler-times {\tvwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d -mrvv-vector-bits=scalable" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (int64_t, int32_t)
+
+/* { dg-final { scan-assembler-times {\tvwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d -mrvv-vector-bits=scalable" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (int16_t, int8_t)
+
+/* { dg-final { scan-assembler-times {\tvwmul\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d -mrvv-vector-bits=scalable" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (uint32_t, uint16_t)
+
+/* { dg-final { scan-assembler-times {\tvwmulu\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d -mrvv-vector-bits=scalable" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (uint64_t, uint32_t)
+
+/* { dg-final { scan-assembler-times {\tvwmulu\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=rv32gcv -mabi=ilp32d -mrvv-vector-bits=scalable" } */
+
+#include "cond_widen_complicate-3.h"
+
+TEST_TYPE (uint16_t, uint8_t)
+
+/* { dg-final { scan-assembler-times {\tvwmulu\.vv} 1 } } */
+/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
deleted file mode 100644
@@ -1,36 +0,0 @@
-/* { dg-do compile } */
-/* { dg-additional-options "-march=rv32gcv_zvfh -mabi=ilp32d -mrvv-vector-bits=scalable -ffast-math" } */
-
-#include <stdint-gcc.h>
-
-#define TEST_TYPE(TYPE1, TYPE2) \
- __attribute__ ((noipa)) void vwadd_##TYPE1_##TYPE2 ( \
- TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3, \
- TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b, \
- TYPE2 *__restrict a2, TYPE2 *__restrict b2, int *__restrict pred, int n) \
- { \
- for (int i = 0; i < n; i++) \
- { \
- dst[i] = pred[i] ? (TYPE1) a[i] * (TYPE1) b[i] : dst[i]; \
- dst2[i] = pred[i] ? (TYPE1) a2[i] * (TYPE1) b[i] : dst2[i]; \
- dst3[i] = pred[i] ? (TYPE1) a2[i] * (TYPE1) a[i] : dst3[i]; \
- dst4[i] = pred[i] ? (TYPE1) a[i] * (TYPE1) b2[i] : dst4[i]; \
- } \
- }
-
-#define TEST_ALL() \
- TEST_TYPE (int16_t, int8_t) \
- TEST_TYPE (uint16_t, uint8_t) \
- TEST_TYPE (int32_t, int16_t) \
- TEST_TYPE (uint32_t, uint16_t) \
- TEST_TYPE (int64_t, int32_t) \
- TEST_TYPE (uint64_t, uint32_t) \
- TEST_TYPE (float, _Float16) \
- TEST_TYPE (double, float)
-
-TEST_ALL ()
-
-/* { dg-final { scan-assembler-times {\tvwmul\.vv} 12 } } */
-/* { dg-final { scan-assembler-times {\tvwmulu\.vv} 12 } } */
-/* { dg-final { scan-assembler-times {\tvfwmul\.vv} 8 } } */
-/* { dg-final { scan-assembler-not {\tvmerge\.vvm\t} } } */
new file mode 100644
@@ -0,0 +1,21 @@
+#ifndef COND_WIDEN_COMPLICATE_3_H
+#define COND_WIDEN_COMPLICATE_3_H
+
+#include <stdint-gcc.h>
+
+#define TEST_TYPE(TYPE1, TYPE2) \
+ __attribute__ ((noipa)) void vwadd_##TYPE1##_##TYPE2 ( \
+ TYPE1 *__restrict dst, TYPE1 *__restrict dst2, TYPE1 *__restrict dst3, \
+ TYPE1 *__restrict dst4, TYPE2 *__restrict a, TYPE2 *__restrict b, \
+ TYPE2 *__restrict a2, TYPE2 *__restrict b2, int *__restrict pred, int n) \
+ { \
+ for (int i = 0; i < n; i++) \
+ { \
+ dst[i] = pred[i] ? (TYPE1) a[i] * (TYPE1) b[i] : dst[i]; \
+ dst2[i] = pred[i] ? (TYPE1) a2[i] * (TYPE1) b[i] : dst2[i]; \
+ dst3[i] = pred[i] ? (TYPE1) a2[i] * (TYPE1) a[i] : dst3[i]; \
+ dst4[i] = pred[i] ? (TYPE1) a[i] * (TYPE1) b2[i] : dst4[i]; \
+ } \
+ }
+
+#endif