Compiling natively GHC for ARMv7l softabi

[Moritz Angermann]

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/compiler/llvmGen/LlvmCodeGen/Ppr.hs#L35-L86
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 at nanotek.info wrote:
> 
> October 22, 2017 11:51 AM, "Moritz Angermann" <moritz.angermann at gmail.com> 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.
> <StgStartup.ll>_______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs