llvm dev - Jan 2014 - [LLVMdev] AArch64: GHC compilation issue.

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

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.