srem-related vector miscompile on AArch64

[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:

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:

#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

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: John Regehr (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

[topperc]

I think this reproduces on X86 too?

[regehr]

it does repro on x86-64. sorry, I should have checked that last night, was being lazy

[topperc]

Looks like maybe an issue with the algorithm in TargetLowering::prepareSREMEqFold for N=INT_MIN and D is a power of 2. I think that comes from Hacker's Delight.

[topperc]

I think the issue is that q=mod(n*multiplicative_inverse(d0), 2^W) is not in the range [-2147483647, 2147483647] when n is -2147483648. So the thoerem that gives the rotate right trick doesn't apply.

CC: @RKSimon @LebedevRI