Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

error: couldn't allocate output register for constraint '{rsp}' at line 2148942589 #46537

Open Quuxplusone opened 4 years ago

Quuxplusone commented 4 years ago
Bugzilla Link PR47568
Status NEW
Importance P enhancement
Reported by Pengbin Feng (pfeng4@gmu.edu)
Reported on 2020-09-17 16:35:50 -0700
Last modified on 2020-09-18 18:16:54 -0700
Version 11.0
Hardware PC Linux
CC craig.topper@gmail.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also
When I want to generate the assembly file of "arch/x86/kernel/cpu/bugs.c", this
file is first compiled into IR file "arch/x86/kernel/cpu/bugs.ll", and next the
IR files is translated into assembly file by llc.

Then I enter the following errors:

> llc -march=x86 arch/x86/kernel/cpu/bugs.ll -o arch/x86/kernel/cpu/bugs.ll.o
<inline asm>:1:8: error: invalid operand for instruction
         btq  %ecx,(%eax)
              ^~~~
note: !srcloc = 2148111198
<inline asm>:1:8: error: invalid operand for instruction
         btq  %ecx,(%eax)
              ^~~~
note: !srcloc = 2148111198
error: couldn't allocate output register for constraint '{rsp}' at line
2148942589
LLVM ERROR: Do not know how to expand the result of this operator!

Stack dump:
0.      Program arguments: llc -march=x86 arch/x86/kernel/cpu/bugs.ll -o
arch/x86/kernel/cpu/bugs.ll.o
1.      Running pass 'Function Pass Manager' on module
'arch/x86/kernel/cpu/bugs.ll'.
2.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@paravirt_read_msr'
 #0 0x0000562817594dfa llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/local/bin/llc+0x1938dfa)
 #1 0x0000562817592ba4 llvm::sys::RunSignalHandlers() (/usr/local/bin/llc+0x1936ba4)
 #2 0x0000562817592cf3 SignalHandler(int) (/usr/local/bin/llc+0x1936cf3)
 #3 0x00007f99bde798a0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x128a0)
 #4 0x00007f99bcb2af47 raise (/lib/x86_64-linux-gnu/libc.so.6+0x3ef47)
 #5 0x00007f99bcb2c8b1 abort (/lib/x86_64-linux-gnu/libc.so.6+0x408b1)
 #6 0x000056281750dd36 llvm::report_fatal_error(llvm::Twine const&, bool) (/usr/local/bin/llc+0x18b1d36)
 #7 0x000056281750de58 (/usr/local/bin/llc+0x18b1e58)
 #8 0x00005628174c912d llvm::DAGTypeLegalizer::ExpandIntegerResult(llvm::SDNode*, unsigned int) (/usr/local/bin/llc+0x186d12d)
 #9 0x0000562817456485 llvm::DAGTypeLegalizer::run() (/usr/local/bin/llc+0x17fa485)
#10 0x0000562817456c4e llvm::SelectionDAG::LegalizeTypes()
(/usr/local/bin/llc+0x17fac4e)
#11 0x00005628173f6330 llvm::SelectionDAGISel::CodeGenAndEmitDAG()
(/usr/local/bin/llc+0x179a330)
#12 0x00005628173fa6fb
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&)
(/usr/local/bin/llc+0x179e6fb)
#13 0x00005628173fc7bd
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(.part.825) (/usr/local/bin/llc+0x17a07bd)
#14 0x000056281635eb48 (anonymous
namespace)::X86DAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&)
(/usr/local/bin/llc+0x702b48)
#15 0x0000562816b228b8
llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(/usr/local/bin/llc+0xec68b8)
#16 0x0000562816ec804f llvm::FPPassManager::runOnFunction(llvm::Function&)
(/usr/local/bin/llc+0x126c04f)
#17 0x0000562816ec8741 llvm::FPPassManager::runOnModule(llvm::Module&)
(/usr/local/bin/llc+0x126c741)
#18 0x0000562816ec7281 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(/usr/local/bin/llc+0x126b281)
#19 0x000056281606816f main (/usr/local/bin/llc+0x40c16f)
#20 0x00007f99bcb0db97 __libc_start_main (/lib/x86_64-linux-
gnu/libc.so.6+0x21b97)
#21 0x00005628160cda2a _start (/usr/local/bin/llc+0x471a2a)
Aborted (core dumped)
Quuxplusone commented 4 years ago

I'm guessing a little here, but I think you have a .ll file compiled for 64-bit, but then you asked llc to compile it for 32-bit by specifying -march=x86. What happens if you use -march=x86_64?

Quuxplusone commented 4 years ago
When I execute llc -march=x86-64 arch/x86/kernel/cpu/bugs.ll -o
arch/x86/kernel/cpu/bugs.ll.o, the error is shown in the following.
error: invalid operand for inline asm constraint 'i' at line 2149555151.

I think the IR files are Platform independent.

How to decided that the IR files are compiled for 64-bit?
Quuxplusone commented 4 years ago

IR files are not platform independent. Variable alignment, how function arguments and return values are passed, and many other things can all be platform specific. Plus how many bits are used for C types like size_t are dependent on whether it was compiled for 32 or 64 bits.

You shouldn't need to provide -march at all. The first couple lines of the IR file should include a line that says "target triple" that should tell llc which architecture to use.

Does the code compile successfully to a .o file?