AArch64: GHC compilation issue.

Karel_Gardas · January 8, 2014, 9:02pm

Hello,

I'm trying to build a GHC cross-compiler on amd64/ubuntu13.10 box to target aarch64/ubuntu13.10. The last stage of build where the cross-compiler is already built and is building supporting libraries needed in order to compile even simples Haskell programs fails in LLVM/llc with following output. This is a cut of last line emitted by the GHC cross-compiler with verbose option switched on:

*** LLVM Optimiser:
'/export/home/karel/vcs/llvm-head/Debug+Asserts/bin/opt' '/tmp/ghc2615_0/ghc2615_1.ll' '-o' '/tmp/ghc2615_0/ghc2615_3.bc' '-O1' '--enable-tbaa=true'
*** LLVM Compiler:
'/export/home/karel/vcs/llvm-head/Debug+Asserts/bin/llc' '-march=aarch64' '-O2' '-relocation-model=static' '/tmp/ghc2615_0/ghc2615_3.bc' '-o' '/tmp/ghc2615_0/ghc2615_4.lm_s' '--enable-tbaa=true'
LLVM ERROR: Cannot select: 0x3705b90: i64,i64 = smul_lohi 0x3704f90, 0x364caf0 [ORD=3056] [ID=19]
   0x3704f90: i64,ch = load 0x34297e8, 0x3704180, 0x3650d70<LD8[%ln2YO](tbaa=<badref>)> [ORD=3055] [ID=18]
     0x3704180: i64 = add 0x364eb20, 0x3650a70 [ORD=3051] [ID=17]
       0x364eb20: i64,ch = load 0x34297e8, 0x3703570, 0x3650d70<LD8[inttoptr (i64 add (i64 ptrtoint (i8* @MainCapability to i64), i64 856) to i64*)](tbaa=<badref>)> [ORD=3048] [ID=15]
         0x3703570: i64 = add 0x364c7f0, 0x364e920 [ID=14]
           0x364c7f0: i64 = AArch64ISD::WrapperSmall 0x3703f80, 0x3703870, 0x3705490 [ID=12]
             0x3703f80: i64 = TargetGlobalAddress<i8* @MainCapability> 0 [ID=9]
             0x3703870: i64 = TargetGlobalAddress<i8* @MainCapability> 0 [TF=11] [ID=8]
             0x3705490: i32 = Constant<1> [ID=7]
           0x364e920: i64 = Constant<856> [ID=10]
         0x3650d70: i64 = undef [ID=1]
       0x3650a70: i64 = Constant<8> [ID=2]
     0x3650d70: i64 = undef [ID=1]
   0x364caf0: i64,ch = load 0x34297e8, 0x364eb20, 0x3650d70<LD8[%ln2YH](tbaa=<badref>)> [ORD=3054] [ID=16]
     0x364eb20: i64,ch = load 0x34297e8, 0x3703570, 0x3650d70<LD8[inttoptr (i64 add (i64 ptrtoint (i8* @MainCapability to i64), i64 856) to i64*)](tbaa=<badref>)> [ORD=3048] [ID=15]
       0x3703570: i64 = add 0x364c7f0, 0x364e920 [ID=14]
         0x364c7f0: i64 = AArch64ISD::WrapperSmall 0x3703f80, 0x3703870, 0x3705490 [ID=12]
           0x3703f80: i64 = TargetGlobalAddress<i8* @MainCapability> 0 [ID=9]
           0x3703870: i64 = TargetGlobalAddress<i8* @MainCapability> 0 [TF=11] [ID=8]
           0x3705490: i32 = Constant<1> [ID=7]
         0x364e920: i64 = Constant<856> [ID=10]
       0x3650d70: i64 = undef [ID=1]
     0x3650d70: i64 = undef [ID=1]
In function: ghczmprim_GHCziPrimopWrappers_mulIntMayOflozh_entry

I've observed the same issue with LLVM 3.4 as distributed by Ubuntu 13.10 and with LLVM HEAD compiled on January 6. I'm able to provide the byte-code file which results in this issue, but would first like to know if this is a known issue in AArch64 target support or if I shall submit it somewhere or even if I did some mistake in invoking llc or providing wrong set of options to it. It compiles to amd64 code by default so I added just -march=aarch64 and was in impression that it should be enough to target AArch64 platform... If that's wrong, please let me know.

Thanks!
Karel

TNorthover · January 8, 2014, 9:24pm

Hi Karel,

I've observed the same issue with LLVM 3.4 as distributed by Ubuntu 13.10
and with LLVM HEAD compiled on January 6. I'm able to provide the byte-code
file which results in this issue, but would first like to know if this is a
known issue in AArch64 target support or if I shall submit it somewhere or
even if I did some mistake in invoking llc or providing wrong set of options
to it.

I've certainly not seen similar. Usually "Cannot select" errors are
fixed very quickly since they're so easy to narrow down and fix. I
think this is a real bug and the .ll file would be very useful.

It compiles to amd64 code by default so I added just -march=aarch64
and was in impression that it should be enough to target AArch64 platform...
If that's wrong, please let me know.

That's on the edge of OK. There are numerous tricky ABI issues that
could be caused by simply swapping a -march argument to LLVM . Clang,
for example, wouldn't be able to compile correct C or C++ code with
just that switch. But GHC presumably has less stringent ABI
compatibility requirements, so it might get away with it.

On the other hand, I think x86 (and possibly ARM) has specific code to
handle the GHC calling conventions, which I'm fairly sure AArch64
doesn't. That *might* just be a matter of performance, or it might be
crucial. I kept meaning to get GHC working but never really got around
to it.

Cheers.

Tim.