--- Begin Message ---
Source: orc
Version: 1:0.4.42-3
Severity: important
Dear maintainer,
gst-plugins-bad1.0 fails to build from source when built on a RISC-V CPU
with vector instructions [1], due to a SIGILL in the elements_openjpeg
test. Disabling rvv instruction detection in ORC workarounds the issue.
I tracked the issue down to the following ORC generated code:
0x0000003f878a9220: ld a1,24(a0)
0x0000003f878a9224: ld a2,56(a0)
0x0000003f878a9228: ld a3,64(a0)
0x0000003f878a922c: ld a4,72(a0)
0x0000003f878a9230: ld a5,80(a0)
0x0000003f878a9234: vsetvli t0,zero,e16,m4,ta,ma
0x0000003f878a9238: li t0,4
0x0000003f878a923c: vmv.v.x v16,t0
0x0000003f878a9240: lw t2,8(a0)
0x0000003f878a9244: beqz t2,0x3f878a9308
0x0000003f878a9248: vsetvli t1,t2,e16,m2,ta,ma
0x0000003f878a924c: sub t2,t2,t1
0x0000003f878a9250: vle32.v v24,(a2)
0x0000003f878a9254: vnsrl.wi v8,v24,16
0x0000003f878a9258: vnsrl.wi v0,v24,0
0x0000003f878a925c: vsetvli t0,zero,e16,m4,ta,ma
0x0000003f878a9260: vzext.vf2 v24,v8
0x0000003f878a9264: vsetvli zero,t1,e16,m2,ta,ma
0x0000003f878a9268: vle32.v v4,(a5)
0x0000003f878a926c: vnsrl.wi v8,v4,16
0x0000003f878a9270: vsetvli t0,zero,e16,m4,ta,ma
0x0000003f878a9274: vzext.vf2 v4,v8
0x0000003f878a9278: vadd.vv v12,v24,v4
0x0000003f878a927c: vsetvli zero,t1,e16,m2,ta,ma
0x0000003f878a9280: vle32.v v24,(a3)
0x0000003f878a9284: vnsrl.wi v8,v24,16
0x0000003f878a9288: vsetvli t0,zero,e16,m4,ta,ma
0x0000003f878a928c: vzext.vf2 v24,v8
0x0000003f878a9290: vsetvli zero,t1,e16,m2,ta,ma
0x0000003f878a9294: vle32.v v4,(a4)
0x0000003f878a9298: vnsrl.wi v8,v4,16
0x0000003f878a929c: vsetvli t0,zero,e16,m4,ta,ma
0x0000003f878a92a0: vzext.vf2 v4,v8
0x0000003f878a92a4: vadd.vv v28,v24,v4
0x0000003f878a92a8: li t0,1
0x0000003f878a92ac: vsll.vx v4,v28,t0
0x0000003f878a92b0: vadd.vv v24,v28,v4
0x0000003f878a92b4: vadd.vv v4,v12,v24
0x0000003f878a92b8: vadd.vv v24,v4,v16
0x0000003f878a92bc: li t0,3
0x0000003f878a92c0: vsrl.vx v4,v24,t0
0x0000003f878a92c4: vmax.vx v8,v4,zero
0x0000003f878a92c8: vsetvli zero,zero,e8,m1,ta,ma
=> 0x0000003f878a92cc: vnclipu.wi v8,v8,0
0x0000003f878a92d0: vsetvli zero,zero,e16,m2,ta,ma
0x0000003f878a92d4: vsetvli zero,t1,e32,m4,ta,ma
0x0000003f878a92d8: vzext.vf2 v12,v0
0x0000003f878a92dc: vzext.vf2 v4,v8
0x0000003f878a92e0: vsll.vi v4,v4,16
0x0000003f878a92e4: vor.vv v24,v12,v4
0x0000003f878a92e8: vse32.v v24,(a1)
0x0000003f878a92ec: slli t1,t1,0x2
0x0000003f878a92f0: add a1,a1,t1
0x0000003f878a92f4: add a2,a2,t1
0x0000003f878a92f8: add a3,a3,t1
0x0000003f878a92fc: add a4,a4,t1
0x0000003f878a9300: add a5,a5,t1
0x0000003f878a9304: bnez t2,0x3f878a9248
0x0000003f878a9308: ret
The trap occurs at the vnclipu.wi instruction. But further debugging
shows that it is actually not the relevant instruction. SIGILL happens
because the preceding vsetvli instruction set vtype to vill (unsupported
vector configuration), so any following vector instruction fail.
Digging a bit more into the problem, it is caused by the two following
vsetvli instructions:
0x0000003f878a929c: vsetvli t0,zero,e16,m4,ta,ma
...
0x0000003f878a92c8: vsetvli zero,zero,e8,m1,ta,ma
On the SpacemiT K1 (used by the rv-manda-04 build daemon where it
fails), VLEN=256 bits. Therefore the first vsetvli instruction
configures:
- SEW = 16
- LMUL = 4
- VLMAX = VLEN / SEW * LMUL = 256 / 16 * 4 = 64
- VL = VLMAX (as AVL = x0) = 64
The second instructions configures:
- SEW = 8
- LMUL = 1
- VLMAX = VLEN / SEW * LMUL = 256 / 8 * 1 = 32
Since both rs1 = x0 and rd = x0, the current vl is reused as the AVL.
However, according to the RVV 1.0 specification:
"When rs1=x0 and rd=x0, the instruction operates as if the current
vector length in vl is used as the AVL, and the resulting value is
written to vl, but not to a destination register. This form can only be
used when VLMAX and hence vl is not actually changed by the new SEW/LMUL
ratio. Use of the instruction with a new SEW/LMUL ratio that would
result in a change of VLMAX is reserved. Implementations may set vill in
this case."
The SpacemiT K1 (and also the SpacemiT K3) sets vill in this situation,
which is a permitted way to signal the undefined behaviour of this
sequence. That explains why vtype is set to vill and why the next vector
instruction fails.
I still have to understand why the ORC RVV backend emits such sequence
(and looking at above it also generate redundant vsetvli sequences
without vector instructions in between.
Regards
Aurelien
[1]
https://buildd.debian.org/status/fetch.php?pkg=gst-plugins-bad1.0&arch=riscv64&ver=1.28.5-2&stamp=1784782699&raw=0
--- End Message ---
pgpjWwvA_LFUv.pgp
