Renato Golin wrote: [...]> Try setting armv7a-unknown-linux-gnueabihf and see if it works better.No, that doesn't work either. [...]> JIT was never the forte of ARM and I haven't tried yet, but I doubt > it'll be any Debian misconfiguration. The whole architecture > configuration is a bit odd...Debian's clang packages are totally broken on armhf --- the compiler emits a confused warning about the platform being unrecognised, and then generates softfloat code --- so I was wondering about LLVM itself. (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693208; although I notice that the bug seems to have been resolved without being fixed. clang 3.2 seems to have hit experimental, but that fails in a different way...) If it makes any difference, I'm not using the just-in-time part of the JIT, as it were. I have lazy compilation turned off and have a model where the entire script is compiled into IR code and then to machine code when my app starts. See the init() method here: https://cowlark.com/calculon/artifact/1e496bfd00104bd392b8da9dece45156dffe3039 -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ 𝕻𝖍'𝖓𝖌𝖑𝖚𝖎 𝖒𝖌𝖑𝖜'𝖓𝖆𝖋𝖍 𝕮𝖙𝖍𝖚𝖑𝖍𝖚 𝕽'𝖑𝖞𝖊𝖍 𝖜𝖌𝖆𝖍'𝖓𝖆𝖌𝖑 𝖋𝖍𝖙𝖆𝖌𝖓. │ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/8ea05be4/attachment.sig>
On 8 February 2013 14:28, David Given <dg at cowlark.com> wrote:> Debian's clang packages are totally broken on armhf --- the compiler > emits a confused warning about the platform being unrecognised, and then > generates softfloat code --- so I was wondering about LLVM itself.I'm using Ubuntu on Pandas and Chromebooks and LLVM itself behaves well, with the right set of command line options. Though, I remember that I also had hard-float issues when compiling to IR and then to object, but once I started using the full options that Clang provides by default, things started working. Can you paste the result of a "clang -v -mcpu=CPU file.c" on your box? I want to see what are the arguments and the assembler/linker it's choosing to use. What CPU are we talking about? If that works, it's possible that you'll need to set the flags Clang is doing by default on your front-end, too. If it makes any difference, I'm not using the just-in-time part of the> JIT, as it were. I have lazy compilation turned off and have a model > where the entire script is compiled into IR code and then to machine > code when my app starts. >This is very similar to what I did in my toy compiler, but I didn't use ARM at all. However, that should not have made any difference. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/cb3916f9/attachment.html>
Hi David, For ARM, you will need to use the MCJIT ExecutionEngine as the legacy one is broken for ARM. (call EngineBuilder::setUseMCJIT()). When creating your TargetOptions, setting FloatABIType to FloatABI::Hard should trigger codegen for the correct ABI. Amara
| For ARM, you will need to use the MCJIT ExecutionEngine as the legacy | one is broken for ARM. (call EngineBuilder::setUseMCJIT()). Also remember to include the correct MCJIT headers not the JIT one's: calling setUseMCJIT() with the old JIT headers are the only ones being included just constructs an old JIT, it doesn't spit out a helpful warning like "I can't build an MCJIT JIT for you". (This bit me until Amara pointed it out.) Cheers, Dave
On 08/02/13 14:42, Renato Golin wrote: [...]> Can you paste the result of a "clang -v -mcpu=CPU file.c" on your box? I > want to see what are the arguments and the assembler/linker it's > choosing to use. What CPU are we talking about?The box itself is an Allwinner A10; armv7l. /proc/cpuinfo says it's got swp half thumb fastmult vfp edsp neon vfpv3. I've been unable to find any values for CPU which are accepted (it just says 'unknown target CPU'. I've tried arm, armv7, armv7a, armv7l, arm7, armv4t... Any suggestions? Is there a way to get clang and llc to emit a list of what triples they support? Since I posted my message I notice that clang 3.2 has hit Debian experimental. This no longer produces the warning about an unrecognised platform, but it still generates softfloat code --- I've compared clang's output and gcc, and gcc produces hardfloat code. (Incidentally, I was wrong earlier about clang 3.2 failing. Its output causes ld to produce an assertion message, and it didn't occur to me then to look to see whether it had actually created a binary or not.) Here's what clang 3.2 says with 'clang -v -S -O3 test.c': Debian clang version 3.2-1~exp3 (tags/RELEASE_32/final) (based on LLVM 3.2) Target: arm-unknown-linux-gnueabihf Thread model: posix "/usr/bin/clang" -cc1 -triple armv4t-unknown-linux-gnueabihf -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -fmath-errno -mconstructor-aliases -fuse-init-array -target-abi aapcs-linux -target-cpu arm7tdmi -mfloat-abi hard -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file /home/dg/shared/workspace/calculon/test.s -resource-dir /usr/bin/../lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.2/include -internal-isystem /usr/include/clang/3.2/include/ -internal-externc-isystem /usr/include/arm-linux-gnueabihf -internal-externc-isystem /usr/include/arm-linux-gnueabihf -internal-externc-isystem /usr/include -O3 -fno-dwarf-directory-asm -fdebug-compilation-dir /home/dg/shared/workspace/calculon -ferror-limit 19 -fmessage-length 80 -mstackrealign -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o test.s -x c test.c Clang 3.1: Debian clang version 3.1-8 (branches/release_31) (based on LLVM 3.1) Target: arm-unknown-linux-gnueabihf Thread model: posix clang: warning: unknown platform, assuming -mfloat-abi=soft "/usr/bin/clang" -cc1 -triple armv4t-unknown-linux-gnueabihf -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-abi apcs-gnu -target-cpu arm7tdmi -msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file test.s -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.1/include -internal-isystem /usr/include/clang/3.1/include/ -internal-externc-isystem -internal-externc-isystem /usr/include/arm-linux-gnueabihf -internal-externc-isystem /usr/include/arm-linux-gnueabihf -internal-externc-isystem /usr/include -O3 -fno-dwarf-directory-asm -fdebug-compilation-dir /home/dg/shared/workspace/calculon -ferror-limit 19 -fmessage-length 80 -mstackrealign -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o test.s -x c test.c And here's clang 3.0: Debian clang version 3.0-6 (tags/RELEASE_30/final) (based on LLVM 3.0) Target: arm-unknown-linux-gnueabihf Thread model: posix clang: warning: unknown platform, assuming -mfloat-abi=soft "/usr/bin/clang" -cc1 -triple armv4t-unknown-linux-gnueabihf -S -disable-free -disable-llvm-verifier -main-file-name test.c -mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-abi apcs-gnu -target-cpu arm7tdmi -msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature +soft-float-abi -target-feature -neon -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file test.s -resource-dir /usr/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.0/include -internal-externc-isystem /usr/include/arm-linux-gnueabihf -internal-externc-isystem /usr/include -O3 -ferror-limit 19 -fmessage-length 80 -fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fdiagnostics-show-option -fcolor-diagnostics -o test.s -x c test.c (Sorry for the spammage, but I thought it better to snip too little than too much...) I'm particularly curious about the way that the triple passed into the compiler backend starts 'armv4t' when it's rejected as a CPU type if I specify it manually. [...]> If that works, it's possible that you'll need to set the flags Clang is > doing by default on your front-end, too.But this *should* all be autodetected, right? If I'm using the JIT, I shouldn't need platform-specific knowledge to set up the code generator? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "Of course, on a sufficiently small planet, 40 km/hr is, in fact, │ sufficient to punt the elastic spherical cow into low orbit." --- │ Brooks Moses on r.a.sf.c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/f95f583f/attachment.sig>
On 08/02/13 15:42, David Tweed wrote:> | For ARM, you will need to use the MCJIT ExecutionEngine as the legacy > | one is broken for ARM. (call EngineBuilder::setUseMCJIT()). > > Also remember to include the correct MCJIT headers not the JIT one's: > calling setUseMCJIT() with the old JIT headers are the only ones being > included just constructs an old JIT, it doesn't spit out a helpful warning > like "I can't build an MCJIT JIT for you". (This bit me until Amara pointed > it out.)So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to EngineBuilder, but what actually happens is: LLVM ERROR: Target does not support MC emission! Do I need to do anything else? Also, what's the code quality of MCJIT compared to the old JIT? As I'm basically compiling statically at runtime, I don't mind if LLVM spends time generating the code --- I'm using a module pass, eager code generation and setOptLevel(llvm::CodeGenOpt::Aggressive) --- and right now I'm extremely happy with the quality of the code being emitted for amd64. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "Of course, on a sufficiently small planet, 40 km/hr is, in fact, │ sufficient to punt the elastic spherical cow into low orbit." --- │ Brooks Moses on r.a.sf.c -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130208/1e3f5f71/attachment.sig>
> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else?IIRC, this error might be due to not linking against the MCJIT library component. Add the appropriate flags to your build config, and also ensure that you call InitializeNativeTargetAsmPrinter() and InitializeNativeTargetAsmParser().> Also, what's the code quality of MCJIT compared to the old JIT? As I'm > basically compiling statically at runtime, I don't mind if LLVM spends > time generating the code --- I'm using a module pass, eager code > generation and setOptLevel(llvm::CodeGenOpt::Aggressive) --- and right > now I'm extremely happy with the quality of the code being emitted for > amd64.The MCJIT uses the exact same mechanism as the static code generator so the code quality is therefore good. You should note though that using just the ExecutionEngine codegen optimization level parameter won't run the full set of target independent optimizations that a tool like opt will run. Unfortunately there are inconsistencies in the triple handling between clang and the rest of LLVM. I'm not at my workstation so I can't give much more information at the moment. Amara