https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122277
--- Comment #2 from Robin Dapp <rdapp at gcc dot gnu.org> --- (In reply to Richard Biener from comment #1) > Hmm, I see V4QI being used: > > ~/obj-riscv-g/gcc> /home/rguenther/obj-riscv-g/gcc/xgcc > -B/home/rguenther/obj-riscv-g/gcc/ > /home/rguenther/src/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr118019- > 2.c -march=rv64gcv_zvl512b -mno-vector-strict-align > -fdiagnostics-plain-output -O3 -ftree-vectorize -O3 -march=rv64gcv_zvl512b > -mabi=lp64d -mno-vector-strict-align -ffat-lto-objects -fno-ident -S -o > pr118019-2.s -fdump-tree-vect-details -fopt-info-vec > /home/rguenther/src/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr118019- > 2.c:42:21: optimized: loop vectorized using 4 byte vectors and unroll factor > 4 > /home/rguenther/src/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr118019- > 2.c:34:21: optimized: loop vectorized using 16 byte vectors and unroll > factor 4 Ugh, sorry. I have been working on a local version that has int tmp[4][4]; instead of uint32_t tmp[4][4]; (that's what upstream x264 uses).
