Open kcc opened 12 years ago
That's because the realignment will need another register.
But it indeed fails with -mstackrealign:
clang -m32 bug11395.c -c -mstackrealign bug11395.c:6:7: error: ran out of registers during register allocation
Hm. It compiles fine for me w/o -faddress-sanitizer.
clang -m32 -O1 -c -faddress-sanitizer -fno-omit-frame-pointer bug11395.c bug11395.c:6:7: error: ran out of registers during register allocation "int3" ^
The given example doesn't compile even without -faddress-sanitizer: it requires 7 registers, and there are only 6 registers available.
I had to extend the workaround (r147953). Before that revision codegen fails even if -faddress-sanitizer does not cause stack realignment.
% cat bug11395.c
void foo_386(int *a, const int *b,
unsigned int f, int d,
int h, int *c, int *e, int *g)
{
__asm__ volatile(
"int3"
: "+r"(a),
"+r"(b),
"+r"(c),
"+m"(h)
: "m"( d), "m"(g),
"m"(e) , "m"(f)
: "eax", "edx", "esi", "ecx"
);
}
clang -m32 -O1 -c -faddress-sanitizer -fno-omit-frame-pointer bug11395.c
bug11395.c:6:7: error: ran out of registers during register allocation
"int3"
^
1 error generated.
r144962 added a workaround for AddressSanitizer.
Err, no, I'm pretty sure the issue is that there's an inline asm which requires 7 registers in a function using stack realignment (which means there are only 6 registers available).
Interesting, bugpoint changes it from one to the other.
This is another case where "m" constraints referring to alloca objects get their own register instead of using the stack/frame pointer.
Err, no, I'm pretty sure the issue is that there's an inline asm which requires 7 registers in a function using stack realignment (which means there are only 6 registers available).
This is another case where "m" constraints referring to alloca objects get their own register instead of using the stack/frame pointer.
Attachment is missing.
$ wget https://user-images.githubusercontent.com/1789297/143744272-1d1952a5-f8f5-4b25-8149-1ee230dd0740.gz
$ mv 143744272-1d1952a5-f8f5-4b25-8149-1ee230dd0740 foo.ll
$ llc foo.ll
llc: error: llc: foo.ll:45:68: error: expected comma after getelementptr's type
%mlp_filter_channel = getelementptr inbounds %struct.DSPContext* %c, i32 0, i32 131
^
$ wget wget https://user-images.githubusercontent.com/60944935/143744271-18fd6c63-6f7f-4364-bf90-3d79f2d857a2.gz
$ gunzip 143744271-18fd6c63-6f7f-4364-bf90-3d79f2d857a2.gz
$ mv 143744271-18fd6c63-6f7f-4364-bf90-3d79f2d857a2 foo.ll
$ llc foo.ll
llc: error: llc: foo.ll:8:55: error: expected comma after getelementptr's type
%MyAlloca4.sub = getelementptr inbounds [88 x i32]* %MyAlloca4, i32 0, i32 0
^
$ clang -m32 -O1 -c -fsanitize=address -fno-omit-frame-pointer bug11395.c
bug11395.c:6:7: error: inline assembly requires more registers than available
"int3"
^
1 error generated.
So the .ll test files are outdated, but the issue is still reproducible today w/ clang-15.
@llvm/issue-subscribers-backend-x86
$ clang -m32 bug11395.c -c -mstackrealign
actually causes an ICE in clang-15:
clang: /android0/llvm-project/llvm/lib/CodeGen/RegAllocFast.cpp:921: void (anonymous namespace)::RegAllocFast::defineVirtReg(llvm::MachineInstr &, unsigned int, llvm::Register, bool): Assertion `PhysReg != 0 && "Register not assigned"' failed.
...
#10 0x00000000033e285d (anonymous namespace)::RegAllocFast::defineVirtReg(llvm::MachineInstr&, unsigned int, llvm::Register, bool) RegAllocFast.cpp:0:0
#11 0x00000000033df176 (anonymous namespace)::RegAllocFast::allocateInstruction(llvm::MachineInstr&) RegAllocFast.cpp:0:0
#12 0x00000000033dbd1b (anonymous namespace)::RegAllocFast::runOnMachineFunction(llvm::MachineFunction&) RegAllocFast.cpp:0:0
#13 0x00000000030e003d llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (/android0/llvm-project/llvm/build/bin/clang-15+0x30e003d)
Extended Description
Reproducer: % ./Release+Asserts/bin/llc z.o.ll error: ran out of registers during register allocation
Reduced from ffmpeg sources (with inline assembly) building with AddressSanitizer for x86_32
Observed on r144798