VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file


Trying to build AOT version of vmkit java,
building for that classpath glibj.zip:

$ cd vmkit/tools/vmjc/libvmjc

has eventually, after 50 minutes, brought:
llvm[0]: Compiling glibj.zip to llvm
llvm[0]: Optimizing glibj.zip
llvm[0]: Compiling glibj.zip.bc to native
0 llc 0x0000000000c0e04f
1 llc 0x0000000000c0fc4a
2 libpthread.so.0 0x0000003b6400f0f0
3 libc.so.6 0x0000003b634326c5 gsignal + 53
4 libc.so.6 0x0000003b63433ea5 abort + 373
5 llc 0x0000000000bf07e4
llvm::llvm_unreachable_internal(char const*, char const*, unsigned
int) + 356
6 llc 0x00000000008f353d
7 llc 0x00000000008f3614
8 llc 0x00000000008f85e2
9 llc 0x00000000008f894e
10 llc 0x00000000008fa586
llvm::AsmPrinter::EmitGlobalVariable(llvm::GlobalVariable const*) +
11 llc 0x00000000008f412f
llvm::AsmPrinter::doFinalization(llvm::Module&) + 63
12 llc 0x0000000000ba0369
llvm::FPPassManager::doFinalization(llvm::Module&) + 57
13 llc 0x0000000000ba691f
llvm::FPPassManager::runOnModule(llvm::Module&) + 95
14 llc 0x0000000000ba644e
llvm::MPPassManager::runOnModule(llvm::Module&) + 462
15 llc 0x0000000000ba655d
llvm::PassManagerImpl::run(llvm::Module&) + 125
16 llc 0x000000000051dca0 main + 2672
17 libc.so.6 0x0000003b6341eb1d __libc_start_main + 253
18 llc 0x000000000051bb19
Stack dump:
0. Program arguments:
-relocation-model=pic -disable-fp-elim glibj-optimized.zip.bc -o
1. Running pass 'Function Pass Manager' on module 'glibj-optimized.zip.bc'.
make: *** [glibj.zip.s] Aborted (core dumped)

File sizes: glibj.zip.bc (93Mb), glibj-optimized.zip.bc (93Mb),
glibj-optimized.zip.s was ~>190Mb when this crush occurred.

How this can be corrected?


Attached patch should fix the issue. The unreachable condition was
caused by a constant expression involving an inttoptr from i32. This
results in a zext to 64 bits, but apparently LowerConstant in
AsmPrinter doesn't handle constant expressions involving zext. Aren't
zext constant expressions supported by LLVM?

- Allan

libvmjc.diff (909 Bytes)

Hi Allan,

Thanks for the fix! So is this a bug in LLVM? Can you reduce that to a small test case and file a bug?


2010/8/2 Allan Tong <actong88@gmail.com>

Well, I think there is a bug in vmkit for always trying to do pointer
arithmetic using i32 instead of the target's pointer size, which is
what my patch addressed.

As for whether there is a bug in LLVM, I'm not sure. I've played
around with it some more, and it looks like zext expressions get
constant folded before reaching LowerConstant. The only way I've
triggered the unreachable condition is to make a pointer->i32->pointer
constant expression on a 64bit machine, similar to what vmkit was
doing. Attached is a test case. The commented out expressions don't
trigger the unreachable condition, nor does a simple zext expression.

Is the pointer->i32->pointer case a valid use case? It seems like
such instances would be errors in the user's code, and that it may not
be so bad that LLVM will error on them.

- Allan

test.ll (356 Bytes)

It's not usually useful, but it shouldn't be an error; please file.


Filed as bug #7821.

- Allan