| Issue |
77169
|
| Summary |
srem-related vector miscompile on AArch64
|
| Labels |
backend:AArch64,
llvm:codegen,
miscompilation,
NEON
|
| Assignees |
|
| Reporter |
regehr
|
here's a function `@f` that I believe is being miscompiled and also a glue function `@g` that'll let us test it from C:
```llvm
define <4 x i32> @f(<4 x i32> %0) {
%2 = srem <4 x i32> %0, <i32 1, i32 1, i32 2, i32 3>
%3 = icmp eq <4 x i32> %2, zeroinitializer
%4 = zext <4 x i1> %3 to <4 x i32>
ret <4 x i32> %4
}
define void @g(ptr %p) {
%a = load <4 x i32>, ptr %p
%b = call <4 x i32> @f(<4 x i32> %a);
store <4 x i32> %b, ptr %p
ret void
}
```
here's a test driver:
```c
#include <stdio.h>
int x[] = {0, 0, -2147483648, 0};
void g(int *);
int main(void) {
printf("%d %d %d %d\n", x[0], x[1], x[2], x[3]);
g(x);
printf("%d %d %d %d\n", x[0], x[1], x[2], x[3]);
}
```
on my M1 Mac it gives:
```
Johns-MacBook-Pro:build regehr$ ~/llvm-project/for-alive/bin/llc foo2.ll
Johns-MacBook-Pro:build regehr$ clang test.c foo2.s
Johns-MacBook-Pro:build regehr$ ./a.out
0 0 -2147483648 0
1 1 0 1
Johns-MacBook-Pro:build regehr$
```
but, by inspection, we can see that the second line should have been `1 1 1 1`
the codegen for this one is kind of lengthy, so I hope this explanation suffices, thanks
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
