nicolas geoffray
2010-Aug-03 20:35 UTC
[LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
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? Nicolas 2010/8/2 Allan Tong <actong88 at gmail.com>> On Mon, Jul 19, 2010 at 7:40 PM, Minas Abrahamyan <minas.subs at gmail.com> > wrote: > > Trying to build AOT version of vmkit java, > > building for that classpath glibj.zip: > > > > $ cd vmkit/tools/vmjc/libvmjc > > $ make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 REQUIRES_FRAME_POINTER=1 > > > > 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 > > UNREACHABLE executed! > > 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*) + > > 550 > > 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: > > /home/mn/tests/VMkit/llvm/Release-Asserts/bin/llc > > -relocation-model=pic -disable-fp-elim glibj-optimized.zip.bc -o > > glibj.zip.s > > 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 > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100803/5115acda/attachment.html>
Allan Tong
2010-Aug-04 01:50 UTC
[LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
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 On Tue, Aug 3, 2010 at 4:35 PM, nicolas geoffray <nicolas.geoffray at gmail.com> wrote:> 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? > Nicolas > 2010/8/2 Allan Tong <actong88 at gmail.com> >> >> On Mon, Jul 19, 2010 at 7:40 PM, Minas Abrahamyan <minas.subs at gmail.com> >> wrote: >> > Trying to build AOT version of vmkit java, >> > building for that classpath glibj.zip: >> > >> > $ cd vmkit/tools/vmjc/libvmjc >> > $ make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1 REQUIRES_FRAME_POINTER=1 >> > >> > 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 >> > UNREACHABLE executed! >> > 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*) + >> > 550 >> > 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: >> > /home/mn/tests/VMkit/llvm/Release-Asserts/bin/llc >> > -relocation-model=pic -disable-fp-elim glibj-optimized.zip.bc -o >> > glibj.zip.s >> > 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 >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >-------------- next part -------------- A non-text attachment was scrubbed... Name: test.ll Type: application/octet-stream Size: 356 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100803/f98991de/attachment.obj>
Eli Friedman
2010-Aug-04 23:18 UTC
[LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
On Tue, Aug 3, 2010 at 6:50 PM, Allan Tong <actong88 at gmail.com> wrote:> 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.It's not usually useful, but it shouldn't be an error; please file. -Eli
Possibly Parallel Threads
- [LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
- [LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
- [LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
- [LLVMdev] VMkit AOT build problem: llc crushed on glibj compilation to native(.s) file
- [LLVMdev] [VMKit-2.7] libvmjc.so building problem