blob: e51ae1d6aaf0417a9ecd1572e2ee25a1fd5e081f (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
instruction: 0.975
graphic: 0.795
device: 0.773
other: 0.737
network: 0.736
socket: 0.730
mistranslation: 0.690
semantic: 0.652
boot: 0.569
vnc: 0.496
assembly: 0.459
KVM: 0.396
RISC-V Vector Instruction vssub.vv not saturating
I noticed doing a negate ( 0 – 0x80000000 ) using vssub.vv produces an incorrect result of 0x80000000 (should saturate to 0x7FFFFFFF).
Here is the bit of the code:
vmv.v.i v16, 0
…
8f040457 vssub.vv v8,v16,v8
I believe the instruction encoding is correct (vssub.vv with vd = v8, vs2 = v16, rs1 = v8), but the result does not saturate in QEMU.
I’ve just tested with what I think is the latest branch ( https://github.com/sifive/qemu/tree/rvv-1.0-upstream-v7 commit 26 Feb 2021: 1151361fa7d45cc90d69086ccf1a4d8397931811 ) and the problem still exists.
Thanks for raising this bug case. A fix should be available soon.
This should be a quick fix, we will run couple tests again to ensure the fix doesn't break anything. Thanks~
This was fixed by commit:
commit 65606f21243a796537bfe4708720a9bf4bb50169
Author: LIU Zhiwei <email address hidden>
Date: Fri Feb 12 23:02:21 2021 +0800
target/riscv: Fixup saturate subtract function
The overflow predication ((a - b) ^ a) & (a ^ b) & INT64_MIN is right.
However, when the predication is ture and a is 0, it should return maximum.
Signed-off-by: LIU Zhiwei <email address hidden>
Reviewed-by: Richard Henderson <email address hidden>
Reviewed-by: Alistair Francis <email address hidden>
Message-id: <email address hidden>
Signed-off-by: Alistair Francis <email address hidden>
The fix will be in the QEMU 6.1 release.
|
