Hi, I'm trying to compile the basicmath benchmark from the MiBench suite to the MIPS target. However, when I call llc with the linked llvm bitcode, the compilation gives an error apparently related to some unsupported feature. The same error occurs when I select -march=arm, but it works for X86. In details: Commands I used to compile basicmath: clang -static -O3 basicmath_small.c rad2deg.c cubic.c isqrt.c -c -emit-llvm llvm-link basicmath_small.bc rad2deg.bc cubic.bc isqrt.bc -o basicmath.bc llc basicmath.bc -march=mipsel -relocation-model=static -o basicmath The error is: llc: /home/ronaldo/llvm/include/llvm/Target/TargetLowering.h:302: virtual const llvm::TargetRegisterClass* llvm::TargetLoweringBase::getRegClassFor(llvm::MVT) const: Assertion `RC && "This value type is not natively supported!"' failed. 0 llc 0x0000000001557f2d llvm::sys::PrintStackTrace(_IO_FILE*) + 38 1 llc 0x00000000015581aa 2 llc 0x0000000001557b50 3 libpthread.so.0 0x00007f2d54c26340 4 libc.so.6 0x00007f2d53e62f79 gsignal + 57 5 libc.so.6 0x00007f2d53e66388 abort + 328 6 libc.so.6 0x00007f2d53e5be36 7 libc.so.6 0x00007f2d53e5bee2 8 llc 0x00000000009be707 9 llc 0x0000000000cfed54 llvm::FunctionLoweringInfo::CreateReg(llvm::MVT) + 64 10 llc 0x0000000000cfeebd llvm::FunctionLoweringInfo::CreateRegs(llvm::Type*) + 337 11 llc 0x0000000000cf33fa 12 llc 0x0000000000cfe4cb llvm::FunctionLoweringInfo::set(llvm::Function const&, llvm::MachineFunction&, llvm::SelectionDAG*) + 2033 13 llc 0x0000000000dadb1d llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 921 14 llc 0x0000000000b01037 llvm::MipsDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 35 15 llc 0x0000000000b2a9a1 llvm::MipsSEDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 65 16 llc 0x0000000000fcd6ed llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95 17 llc 0x00000000014d0825 llvm::FPPassManager::runOnFunction(llvm::Function&) + 291 18 llc 0x00000000014d09d0 llvm::FPPassManager::runOnModule(llvm::Module&) + 84 19 llc 0x00000000014d0cee 20 llc 0x00000000014d13b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 244 21 llc 0x00000000014d15c3 llvm::legacy::PassManager::run(llvm::Module&) + 39 22 llc 0x00000000008c4893 23 llc 0x00000000008c3ac3 main + 237 24 libc.so.6 0x00007f2d53e4dec5 __libc_start_main + 245 25 llc 0x00000000008c1589 Stack dump: 0. Program arguments: ../../../sw/llc basicmath.bc -march=mipsel -relocation-model=static -o basicmath 1. Running pass 'Function Pass Manager' on module 'basicmath.bc'. 2. Running pass 'MIPS DAG->DAG Pattern Instruction Selection' on function '@SolveCubic' Aborted (core dumped) Am I missing something in the compilation? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140527/7ad1e9dc/attachment.html>
Hi Ronaldo, On 27 May 2014 18:13, Ronaldo Ferreira <ronaldorferreira at gmail.com> wrote:> clang -static -O3 basicmath_small.c rad2deg.c cubic.c isqrt.c -c -emit-llvm > llvm-link basicmath_small.bc rad2deg.bc cubic.bc isqrt.bc -o basicmath.bc > llc basicmath.bc -march=mipsel -relocation-model=static -o basicmathMy best guess is that the LLVM IR created on line 1 is actually for x86-64 (generated by a Clang targeting x86-64, having included x86-64 headers and so on). When you override the output target on the third line, you would end up feeding the MIPS backend IR that it's not equipped to deal with. Clang's output *does* depend on what it's targeting. If so, you need to create a proper cross-development environment for MIPS (binutils, libc, headers, ...) and point clang at it in the first line (via -target and -sysroot at least, possibly other options too; getting the driver to work properly can be a tricky business. Use "-v" to get it to tell you more about what it's trying to do). Then the later lines should work fine (though you won't need the -march option for llc). Cheers. Tim. P.S. The backends probably shouldn't crash regardless, but the reality is that they're adapted to the kind of IR Clang produces when it knows it's targeting them and other configurations are much less well-tested. Since the alternative is successfully generating wrong code, it's not much of a priority for me at least.
Thanks Tim, I was not aware of that issue with clang. I could compile with: clang --target=mips-linux-gnu --sysroot=/home/ronaldo/CodeSourcery/Sourcery_CodeBench_Lite_for_MIPS_GNU_Linux -static -O3 basicmath_small.c rad2deg.c cubic.c isqrt.c -c -emit-llvm I already had the MIPS toolchain installed. 2014-05-27 19:28 GMT+02:00 Tim Northover <t.p.northover at gmail.com>:> Hi Ronaldo, > > On 27 May 2014 18:13, Ronaldo Ferreira <ronaldorferreira at gmail.com> wrote: > > clang -static -O3 basicmath_small.c rad2deg.c cubic.c isqrt.c -c > -emit-llvm > > llvm-link basicmath_small.bc rad2deg.bc cubic.bc isqrt.bc -o basicmath.bc > > llc basicmath.bc -march=mipsel -relocation-model=static -o basicmath > > My best guess is that the LLVM IR created on line 1 is actually for > x86-64 (generated by a Clang targeting x86-64, having included x86-64 > headers and so on). When you override the output target on the third > line, you would end up feeding the MIPS backend IR that it's not > equipped to deal with. Clang's output *does* depend on what it's > targeting. > > If so, you need to create a proper cross-development environment for > MIPS (binutils, libc, headers, ...) and point clang at it in the first > line (via -target and -sysroot at least, possibly other options too; > getting the driver to work properly can be a tricky business. Use "-v" > to get it to tell you more about what it's trying to do). Then the > later lines should work fine (though you won't need the -march option > for llc). > > Cheers. > > Tim. > > P.S. The backends probably shouldn't crash regardless, but the reality > is that they're adapted to the kind of IR Clang produces when it knows > it's targeting them and other configurations are much less > well-tested. Since the alternative is successfully generating wrong > code, it's not much of a priority for me at least. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140527/df63b9e7/attachment.html>