This patch contains the testcase in PR120378 after the change made to
support the vnclipu variant of the SAT_TRUNC pattern.
PR target/120378
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr120378.c: New test.
Signed-off-by: Edwin Lu <e...@rivosinc.com>
---
.../gcc.target/riscv/rvv/autovec/pr120378.c | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/pr120378.c
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr120378.c
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr120378.c
new file mode 100644
index 00000000000..500028e7a15
--- /dev/null
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr120378.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gcv -mabi=lp64d -O3" } */
+
+#include <stdint.h>
+
+inline uint8_t
+clip_uint8 (int x)
+{
+ return x & (~255) ? (-x) >> 31 : x;
+}
+
+void __attribute__ ((noipa))
+clip_loop (uint8_t *res, int *x, int w)
+{
+ for (int i = 0; i < w; i++)
+ res[i] = clip_uint8 (x[i]);
+}
I realize this is the x264 example mentioned in the PR but wouldn't it make
sense to do some broader testing? Wouldn't the same approach work for (e.g.)
clip_uint16? Or clip_uint8 with short int input?
In the same vein, the shift amount in the match pattern seems very hard-coded
:) rather than dependent on the type precision.
--
Regards
Robin