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.