https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99395
--- Comment #10 from JuzheZhong <juzhe.zhong at rivai dot ai> --- I think the root cause is we think i_16 and _1 are alias due to scalar evolution: (get_scalar_evolution (scalar = i_16) (scalar_evolution = {0, +, 2}<nw>_1)) (get_scalar_evolution (scalar = _1) (scalar_evolution = {1, +, 2}<nw>_1)) Even though I didn't understand what it is. diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc index 25e3130e2f1..2df6de67043 100644 --- a/gcc/tree-scalar-evolution.cc +++ b/gcc/tree-scalar-evolution.cc @@ -553,7 +553,7 @@ get_scalar_evolution (basic_block instantiated_below, tree scalar) if (SSA_NAME_IS_DEFAULT_DEF (scalar)) res = scalar; else - res = *find_var_scev_info (instantiated_below, scalar); + res = scalar; break; case REAL_CST: Ah... I tried an ugly hack which is definitely wrong (just for experiment) in scalar evolution. Then, we can vectorize it: foo: lui a1,%hi(a) addi a1,a1,%lo(a) li a2,511 li a3,0 vsetivli zero,2,e64,m1,ta,ma .L2: addiw a5,a3,1 slli a5,a5,3 add a5,a1,a5 fld fa5,0(a5) slli a4,a3,3 add a4,a1,a4 vlse64.v v2,0(a4),zero vle64.v v1,0(a5) vfslide1down.vf v2,v2,fa5 addiw a2,a2,-1 vfmul.vv v1,v1,v2 vse64.v v1,0(a4) addiw a3,a3,2 bne a2,zero,.L2 ret I think we can add some simple memory access index recognition, but I don't known where to add this recognition. Would you mind giving me some more hints ? Thanks.