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 <[email protected]> --- .../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
