"ran out of registers" while building i386 linux kernel

[arndb]

Bugzilla Link	42569
Version	trunk
OS	Linux
Blocks	#4440
CC	@Aaron1011,@topperc,@efriedma-quic,@fhahn,@RKSimon,@MatzeB,@nickdesaulniers,@qcolombet,@zygoloid,@rotateright

Extended Description

One file in the linux kernel produces an internal error from the register allocator. I reduced the test case to this:

typedef int (*tune_freq_func_t)(int , void * tuneargs);
static struct {
  int power_up;
  int power_down;
  tune_freq_func_t fm_tune_freq;
  tune_freq_func_t am_tune_freq;
  int fm_rsq_status;
  int agc_status;
  int intb_pin_cfg;
} a[1];
int b, c;
int fn1(void) { return a[c].fm_tune_freq(b, fn1); }

$ clang-9 -m32 -mregparm=3 -O2 -fno-strict-overflow -c si476x-cmd.c
error: ran out of registers during register allocation
1 error generated.

See https://godbolt.org/z/aQ96HC

[efriedma-quic]

This looks similar to https://reviews.llvm.org/rL163819

[efriedma-quic]

This isn't really a register allocator issue; there aren't enough registers available in the register class in question.

[Aaron1011]

Minimized:

target datalayout = "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-f64:32:64-f80:32-n8:16:32-S128"
target triple = "i386-unknown-linux-gnu"

%bigstruct = type { void (i32, i32)*, i32, i32, i32, i32, i32, i32 }

@bigconst = constant [1 x %bigstruct] zeroinitializer
@zero = global i32 0

define void @main() {
  %1 = load i32, i32* @zero
  %2 = getelementptr [1 x %bigstruct], [1 x %bigstruct]* @bigconst, i32 %1, i32 0, i32 0
  %3 = load void (i32, i32)*, void (i32, i32)** %2
  tail call void %3(i32 inreg 0, i32 inreg 1)
  ret void
}

[Aaron1011]

There's some special handling of tail calls with inreg arguments (for 32-bit X86) in X86TargetLowering::IsEligibleForTailCallOptimization, which seems potentially relevant.

[arndb]

I came across another instance of the output:

clang-14 --target=x86_64-linux  -m32 -O2 -fno-omit-frame-pointer -c nf_synproxy_core.i
nf_synproxy_core.i:22:7: error: inline assembly requires more registers than available
  asm("" : "=&r"(d) : "r"(a), "r"(b), "r"(0), "r"(c), "0"(d));
      ^

based one the input below (reduced with cvise):

int a, b, d, j, l, e, g;
char c;
struct e {
  char f;
};
struct g {
  struct e h;
};
struct i {
} m(void), f, h;
enum { k } n(struct i *, struct e *);
struct {
  short ac;
} * o, *q;
int (*p)();
_Bool r;
short s, t;
unsigned char *u;
void v(void);
static void w(int *x, struct i *z) {
  struct g y;
  asm("" : "=&r"(d) : "r"(a), "r"(b), "r"(0), "r"(c), "0"(d));
  q->ac = 0;
  t = (unsigned char *)q - u;
  s = y.h.f = k;
  n(z, &(&y)->h);
  if (o)
    p(x, j, l, r);
  v();
  m();
}
void aa() { w(&e, &f); }
void ab() { w(&g, &h); }

The above happens with clang-12 through at least clang-14, but not with clang-11.

And there is one more in 64-bit mode that I have not reduced but could if that helps:

arch/x86/crypto/curve25519-x86_64.c:519:3: error: inline assembly requires more registers than available
                "  movq 0(%1), %%rdx;"                                       /* f[0] */
                ^

[nickdesaulniers]

Perhaps relevant to -fno-omit-frame-pointer. It looks like gcc-8 stopped obeying that for -m32. That's probably what's causing register pressure for LLVM.

https://godbolt.org/z/a7K8dddPG

[nickdesaulniers]

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8e941ae950ddce1745b4d6819a7131908dd7de24 looks relevant.

[nickdesaulniers]

Perhaps a clang-12 regression?
https://godbolt.org/z/fos3r6x7d

[nickdesaulniers]

Perhaps a clang-12 regression? https://godbolt.org/z/fos3r6x7d

Bisection converged on https://reviews.llvm.org/D83996. (cc @topperc, @phoebewang ); doesn't look like a regression per se. But it definitely looks like having a scheduling model or not affects this, since we were also seeing issues for -march=atom.

[topperc]

There are two copies from EAX and EDX into virtual regsiters at the start of the function immediately after isel. Those got re-scheduled after the inline assembly which oversubscribed the register allocator for the inline assembly.

[topperc]

Adding

def  : InstRW<[WriteMove], (instrs COPY)>;

to the SandyBridge scheduler model makes it go away.