
Thanks! Looking at the llvm ir file, we find: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32" target triple = "armv6-unknown-linux-gnueabihf" that does looks incorrect for armv7l softabi. We have the hardfloat gnueabi, AND armv6. However, I don't know if this influences the generated IR to the point where it's unusable. Looking at https://github.com/ghc/ghc/blob/95c1feeb9ce9b2d6a9453dc4da148b80a5ddce3d/com... I don't see a proper configuration for it yet though. Now again we mix the llvm and gcc toolchain, and I don't have gcc on my system right now. We can do the following though: $ llc -O3 StgStartup.ll -o StgStartup.s $ clang --target=arm-unknown-linux-gnueabihf -c StgStartup.s -v and have this successfully produce an object file. As such I don't think the target triple given above is at fault here (apart from potentially generating hard-float fp). I would as such conclude that the issue is the argument passed to gcc as assembler here. I'm a bit at a loss how to solve this here right now. GHC HEAD has seen especially in this area quite a bit of churn as well. On top of my head, I've two suggestions: - Try configuring with a LLVM toolchain. E.g. CC=arm-linux-gnueabi-clang - Try GHC HEAD. If this still fails, you could try to sidestep the mangling and assembly logic, by adding -fast-llvm to the mk/flavour/<your-flavour>.mk (e.g. quick-cross, perf-cross). Cheers, Moritz
On Oct 22, 2017, at 4:05 PM, shiftag@nanotek.info wrote:
October 22, 2017 11:51 AM, "Moritz Angermann"
wrote: Can you rerun that command with -keep-llvm-files and attach the generated .ll file?
I rerun the same command by adding -keep-llvm-files and the file "./rts/StgStartup.ll" has been created. Please find it attached.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs