[Bug tree-optimization/122277] Costing VF 1 instead of 4 since r16-4411-gb6e802fd55d37e

[rdapp at gcc dot gnu.org]

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).