https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122635
Bug ID: 122635
Summary: RISC-V: -mrvv-vector-bits=zvl introducing unoptimal
vsetivli zero,0 and insns depending on AVL nops
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ewlu at rivosinc dot com
Target Milestone: ---
Below is a snippet reduced from the spec2017 blender benchmark:
typedef struct {
int a[6];
float b[3];
} c;
int d(c *e) {
int f =0;
for (; f < 3; f++) {
e->a[2 * f] = e->b[f];
e->a[2 * f + 1] = -e->a[2 * f];
e->a[2 * f] = f + 3 * e->a[2 * f];
e->a[2 * f + 1] = f + 3 * e->a[2 * f + 1];
}
return 0;
}
where we're currently generating the following unoptimal code:
...
vsetivli zero,3,e32,m1,ta,ma
vsseg2e32.v v4,(a5)
vsetivli zero,0,e32,m1,ta,ma
vadd.vi v4,v1,4 <-- AVL == 0, nop
vsetivli zero,6,e32,m1,ta,ma
li a0,0
vle32.v v3,0(a5)
vsetivli zero,0,e32,m1,ta,ma
vle32.v v2,0(a4) <-- AVL == 0, nop
vsetivli zero,6,e32,m1,ta,ma
vmadd.vv v3,v6,v1
vmv1r.v v1,v2
vsetivli zero,0,e32,m1,ta,ma
vmadd.vv v1,v6,v4 <-- AVL == 0, nop
vsetivli zero,6,e32,m1,ta,ma
vse32.v v3,0(a5)
vsetivli zero,0,e32,m1,ta,ma
vse32.v v1,0(a4) <-- AVL == 0, nop
ret
Godbolt: https://godbolt.org/z/dhcjbEf9G
Left is with -mrvv-vector-bits=zvl and right is without
For some reason, the AVL info at expand time is populated as 0 which seems like
a bug to me. We should never be setting AVL == imm_0 since any instruction
emitted after which depends on AVL will become a nop.
