Error in backend: Ran out of registers during register allocation!

[llvmbot]

Bugzilla Link	6309
Resolution	FIXED
Resolved on	Jun 25, 2010 16:56
Version	trunk
OS	Windows NT
Blocks	llvm/llvm-bugzilla-archive#6815
Attachments	Preprocessed file.
Reporter	LLVM Bugzilla Contributor
CC	@efriedma-quic,@stoklund

Extended Description

clang version 1.1 (trunk 95495)
Target: i686-pc-mingw32
Thread model: posix

I've attached the preprocessed file.

[llvmbot]

I don't have a super-recent build of clang; I'll build one. With my build about a week old I'm not getting the same error, perhaps for environmental reasons or perhaps because somebody improved this message recently IIRC, but I do get:

fatal error: error in backend: Invalid operand found in inline asm: 'push %ebp
push $$0
push $$0
push $$Return${:uid}
push $0
call ${1:c}
Return${:uid}: pop %ebp
'
INLINEASM <es:push %ebp
push $$0
push $$0
push $$Return${:uid}
push $0
call ${1:c}
Return${:uid}: pop %ebp

, 44, %EBP, 1, %reg0, -32, %reg0, 44, %EBP, 1, %reg0, -36, %reg0, 14, %AX<earlyclobber,def,dead>, 14, %BX<earlyclobber,def,dead>, 14, %CX<earlyclobber,def,dead>, 14, %DX<earlyclobber,def,dead>, 14, %SI<earlyclobber,def,dead>, 14, %DI<earlyclobber,def,dead>, 14, %EFLAGS<earlyclobber,def,dead>, 14, %EFLAGS<earlyclobber,def,dead>

This comes from

asm volatile
(
"push %%ebp\n"
"push $0\n"
"push $0\n"
"push $Return%=\n"
"push %[target]\n"
"call %c[RtlUnwind]\n"
"Return%=: pop %%ebp\n" :
:
[target] "g" (target), [RtlUnwind] "g" (&RtlUnwind) :
"eax", "ebx", "ecx", "edx", "esi", "edi", "flags", "memory"
);

llvm doesn't know what $Return means, nor do I.

fwiw, this file doesn't come close to going through llvm-g++. I'm not a C++ language expert but I suspect clang is accepting some stuff it shouldn't be.

[llvmbot]

C++ ? this is a portion of c code.

[llvmbot]

Oh. It is even farther away from going through llvm-gcc; there are hundreds of errors.

[llvmbot]

A reduced testcase.

[llvmbot]

A reduced testcase.

[efriedma-quic]

I can't reproduce; can you try again with trunk?

[llvmbot]

I can't reproduce; can you try again with trunk?

I can still reproduce it. Tested with : clang version 1.5 (trunk 101072)

Target: i686-pc-mingw32
Thread model: posix

[llvmbot]

Still exists. Tested with :
clang version 1.5 (trunk 102070)
Target: i686-pc-mingw32
Thread model: posix

[stoklund]

I can't reproduce this. Please attach a bitcode file.

[llvmbot]

Bitcode file.

[llvmbot]

I could reproduce it with clang version 2.0 (trunk 103176)
Target: i686-pc-mingw32
The bitcode file is attached.

[llvmbot]

I can reproduce this, from testcase3.c, on x86_86-linux-unknown-gnu. Passing -m32 gives me the assert 'i != PhysRegsUseOrder.size() && "Couldn't find a register of the appropriate class!', while the default (64 bit) gives me:

/tmp/cc-WxevLz.s: Assembler messages:
/tmp/cc-WxevLz.s:23: Error: suffix or operands invalid for push' /tmp/cc-WxevLz.s:28: Warning: indirect call without *'
/tmp/cc-WxevLz.s:29: Error: suffix or operands invalid for `pop'

on i386-apple-darwin10 I get:

fatal error: error in backend: Invalid operand found in inline asm: 'push %ebp
push $$0
push $$0
push $$Return${:uid}
push $0
call ${1:c}
Return${:uid}: pop %ebp
'
INLINEASM <es:push %ebp
push $$0
push $$0
push $$Return${:uid}
push $0
call ${1:c}
Return${:uid}: pop %ebp

, 44, %RBP, 1, %reg0, -32, %reg0, 44, %RBP, 1, %reg0, -40, %reg0, 14, %AX<earlyclobber,def,dead>, 14, %BX<earlyclobber,def,dead>, 14, %CX<earlyclobber,def,dead>, 14, %DX<earlyclobber,def,dead>, 14, %SI<earlyclobber,def,dead>, 14, %DI<earlyclobber,def,dead>, 14, %EFLAGS<earlyclobber,def,dead>, 14, %EFLAGS<earlyclobber,def,dead>

I notice that the lines which are complained about are exactly those inserted via the inline asm.

[stoklund]

RegAllocLocal.cpp is no longer, and the bitcode passes through llc -O0 without problems.
Please provide a new bitcode file if the problem persists.

[llvmbot]

clang version 2.0 (trunk 106854)
Target: i686-pc-mingw32
Thread model: posix

fatal error: error in backend: Ran out of registers during register allocation!
Please check your inline asm statement for invalid constraints:
INLINEASM <es:push %ebp
push $$0
push $$0
push $$Return${:uid}
push $0
call ${1:c}
Return${:uid}: pop %ebp

, 44, <fi#2>, 1, %reg0, 0, %reg0, 11, %reg1027, 14, %AX<earlyclobber,imp-
def>, 14, %BX<earlyclobber,imp-def>, 14, %CX<earlyclobber,imp-def>, 14, %DX<earl
yclobber,imp-def>, 14, %SI<earlyclobber,imp-def>, 14, %DI<earlyclobber,imp-def>,
14, %EFLAGS<earlyclobber,imp-def>, 14, %EFLAGS<earlyclobber,imp-def>, <!-1>

[llvmbot]

clang -emit-llvm -S gives :

; ModuleID = 'testcase4.c'
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i686-pc-mingw32"

%struct.__SEH2Frame = type {}

define void @​_SEH2FrameHandler() nounwind {
entry:
%target.addr.i = alloca i8*, align 4 ; <i8**> [#uses=2]
%frame = alloca %struct.__SEH2Frame*, align 4 ; <%struct.__SEH2Frame**> [#uses=1]
%tmp = load %struct.__SEH2Frame** %frame ; <%struct.__SEH2Frame*> [#uses=1]
%conv = bitcast %struct.__SEH2Frame* %tmp to i8* ; <i8*> [#uses=1]
store i8* %conv, i8** %target.addr.i
%tmp.i = load i8** %target.addr.i ; <i8*> [#uses=1]
call void asm sideeffect "push %ebp\0Apush $$0\0Apush $$0\0Apush $$Return${:uid}\0Apush $0\0Acall ${1:c}\0AReturn${:uid}: pop %ebp\0A", "imr,imr,{ax},{bx},{cx},{dx},{si},{di},{flags},{memory},{dirflag},{fpsr},~{flags}"(i8* %tmp.i, void (...)* @​RtlUnwind) nounwind, !srcloc !​0
ret void
}

declare x86_stdcallcc void @​RtlUnwind(...)

!​0 = metadata !{i32 215}

[stoklund]

The LLVM code generator does not fully support the polymorphic "g" constraint. It is basically treated as an "r" constraint.

Your inline asm does not leave enough registers available for all the "g" constraints.

Please choose which argument should be a memory reference, and use an "m" constraint for that one instead.

[llvmbot]

The fact that GCC does accept such code means a bug in clang ? or in gcc ? or ?

[stoklund]

The GCC inline asm syntax provides direct hooks into the guts of GCC.
We are aiming to provide compatibility for most cases, but we cannot fully emulate all of GCC's behavior.
Does the "m" constraint work for you?

[llvmbot]

Actually "g" is supposed to be reducing to "m" in doubtful cases. The choice is made before there is any info about register availability, so this may produce inferior code to gcc, but should work. With Jakob's help I was finally able to reproduce this and I'm looking at it.

[llvmbot]

Should be fixed in 106893.

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#6815