https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #7 from JuzheZhong ---
(In reply to Kito Cheng from comment #6)
> The key is the splat of VLMAX instruction need move into loop body, but AVL
> propagation should still able to do:
>
> ```
> foo(int, int*, int*):
> ble a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #6 from Kito Cheng ---
The key is the splat of VLMAX instruction need move into loop body, but AVL
propagation should still able to do:
```
foo(int, int*, int*):
ble a0,zero,.L5
csrra5,vlenb
srlia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #5 from Kito Cheng ---
Assume:
VLEN = 128 and n = 5, *in is {0, 0, 0, 0, 0}
so VLMAX = 4 for e32m1
It can be run with vl = 4 for first iteration, and vl = 1 vl for second
iteration
But it could be something like that: vl = 3 for f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #4 from JuzheZhong ---
Oh. I see what you mean.
I think it may not be the valid optimization.
Since the following codes:
.L3:
vsetvli a5,a0,e32,m1,ta,ma
sllia4,a5,2
vle32.v v1,0(a1)
sub a0,a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #3 from JuzheZhong ---
You mean current codegen is bug ?
No, I don't think there is a bug in current codegen.
It's induction variable.
ble a0,zero,.L5
...
vsetvli a3,zero,e32,m1,ta,ma
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
--- Comment #2 from Kito Cheng ---
oh, but the root cause might be little bit deeper, not just the problem of
propagation or not propagation the AVL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112438
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #1 fro
