lli barfs with "pseudo instructions should be removed before code emission"

[Quuxplusone]

Bugzilla Link	PR10279
Status	NEW
Importance	P normal
Reported by	Stephen Kell (srk31@srcf.ucam.org)
Reported on	2011-07-05 05:35:16 -0700
Last modified on	2011-08-16 05:15:47 -0700
Version	2.9
Hardware	PC Linux
CC	efriedma@quicinc.com, geek4civic@gmail.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

I'm getting the following strange error from lli.

$ lli out/host/linux-
x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc.bc
pseudo instructions should be removed before code emission
UNREACHABLE executed at X86CodeEmitter.cpp:720!
0  lli             0x0000000000e3b2ff
1  lli             0x0000000000e3bd63
2  libpthread.so.0 0x0000003b7f60f4a0
3  libc.so.6       0x0000003b7ea328f5 gsignal + 53
4  libc.so.6       0x0000003b7ea340d5 abort + 373
5  lli             0x0000000000e1e3ac
6  lli             0x000000000067f482
7  lli             0x00000000006809a5
8  lli             0x0000000000dadec7
llvm::FPPassManager::runOnFunction(llvm::Function&) + 567
9  lli             0x0000000000dadffb
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 139
10 lli             0x0000000000dae169
llvm::FunctionPassManager::run(llvm::Function&) + 105
11 lli             0x00000000008f09be
llvm::JIT::jitTheFunction(llvm::Function*, llvm::MutexGuard const&) + 46
12 lli             0x00000000008f35ec
llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) +
28
13 lli             0x00000000008f3870
llvm::JIT::getPointerToFunction(llvm::Function*) + 272
14 lli             0x00000000008f1fa4 llvm::JIT::runFunction(llvm::Function*,
std::__debug::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> >
const&) + 52
15 lli             0x0000000000c7b42d
llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::__debug::vector<std::string, std::allocator<std::string> > const&, char
const* const*) + 1757
16 lli             0x0000000000617dfc main + 1612
17 libc.so.6       0x0000003b7ea1ec5d __libc_start_main + 253
18 lli             0x000000000061f1ad
Stack dump:
0.      Program arguments: lli out/host/linux-
x86/pr/sim/obj/EXECUTABLES/dalvikvm_intermediates/LINKED/dalvikvm.bc.bc
1.      Running pass 'X86 Machine Code Emitter' on function '@main'
Aborted (core dumped)

This is with a Release+Debug+Asserts+Checks build of the 2.9 release, on a FC13
x86-64 machine.

You can probably reproduce with the following bitcode file:
<http://www.cs.ox.ac.uk/people/stephen.kell/private/llvm-bug-
20110705/dalvikvm.bc.bc>. (I was expecting it to need external bitcode
libraries that I built alongside it, but it gets at least as far as the bug
without them. Maybe they're already linked in -- I don't yet understand bitcode
linkage enough to say.)

To investigate further, I hacked X86CodeEmitter.cpp as follows:

--- lib/Target/X86/X86CodeEmitter.cpp   2010-10-09 00:59:27.000000000 +0100
+++ lib/Target/X86/X86CodeEmitter-hacked.cpp    2011-07-04 16:10:44.000000000
+0100
@@ -715,6 +715,7 @@
     // base address.
     switch (Opcode) {
     default:
+       dbgs() << MI;
       llvm_unreachable("pseudo instructions should be removed before code"
                        " emission");
       break;

which prints

DBG_VALUE 0, 0, !"needExtra"; dbg:Main.c:149

and the relevant bit of Main.c looks like this:

148    int optionCount, curOpt, i, argIdx;
149    int needExtra = JNI_FALSE;
150    int result = 1;

... i.e. nothing out of the ordinary. The disassembly looks normal too,
although I wouldn't really know.

Here's a (carefully snipped) log showing how make built the bitcode file:
<http://www.cs.ox.ac.uk/people/stephen.kell/private/llvm-bug-20110705/make-n-edited.log>

[Quuxplusone]

Does this reproduce with trunk LLVM?

[Quuxplusone]

(In reply to comment #1)
> Does this reproduce with trunk LLVM?

Trunk lli on the same bitcode gives me the same behaviour. I'll report back
when I've rebuilt the bitcode using a complete toolchain from trunk.  (Building
llvm-gcc against trunk is giving me some trouble right now.)

[Quuxplusone]

Hmm... also, does the same bitcode crash if you run it through llc?

[Quuxplusone]

Nope -- llc processes the file without complaint and produces some reasonable-looking assembly as output.

(That said, I don't know how to assemble it -- llvm-as complains at the first .file directive, saying "expected top-level entity", and llvm-gcc doesn't understand the "calll" and similar instructions.)

[Quuxplusone]

Hmm... then it's probably a bug in the JIT codepath. Note that nobody is really maintaining that code at the moment... it's mostly going to get replaced, but the work to do that is stalled at the moment.

[Quuxplusone]

Okay -- thanks for letting me know. It turns out I don't desperately need lli. I was just using it as a sanity check. If I find any different behaviour with rebuilds from more recent llvm, I'll post an update here.