blob: 993bac92ef9ab7d335ae5422c1aa2530fd4d71e0 (
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
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
instruction: 0.901
assembly: 0.741
mistranslation: 0.694
device: 0.653
graphic: 0.618
socket: 0.439
vnc: 0.390
network: 0.364
other: 0.326
boot: 0.235
semantic: 0.210
KVM: 0.187
loongarch64: wrong implementation of `xvldi` instruction
Description of problem:
Consider this sample program.
```c++
#include <cstdio>
#include <cstdint>
#include <lsxintrin.h>
#include <lasxintrin.h>
void dump_u32(__m256i x) {
uint32_t tmp[32/4];
__lasx_xvst(x, tmp, 0);
putchar('[');
for (int i=0; i < 32/4; i++) {
if (i > 0) {
putchar(' ');
}
printf("%08x", tmp[i]);
}
puts("]");
}
int main() {
__m256i const1 = __lasx_xvldi(-3832);
dump_u32(const1);
}
```
The magic constants here means: replicate in 32-bit words a byte (0x4) shifted left by 8. We should have a vector of words 0x800, and indeed, the program run on a real hardware prints expected:
```
[00000800 00000800 00000800 00000800 00000800 00000800 00000800 00000800]
```
The same program run under Qemu prints:
```
[08000800 00000000 08000800 00000000 08000800 00000000 08000800 00000000]
```
Additional information:
I grabbed the latest sources, it seems there's bug in `target/loongarch/tcg/insn_trans/trans_vec.c.inc`, in function `vldi_get_value`.
```c
case 1:
/* data: {2{16'0, imm[7:0], 8'0}} */
data = (t << 24) | (t << 8);
break;
```
There should be `(t << (8+32)) | t << 8`.
|