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.

Reply via email to