Nathan,
llvm-3.1 (Ubuntu 12.10 stock verison) was what gave the bad code I
mentioned previously (see below).
Note: llvm can be very easily built from source. The location of llc and
friends is detected by GHC's configure.
llvm-3.2 gives this code, which looks correct:
00000000 :
0: e594608c ldr r6, [r4, #140] ; 0x8c
4: e3a03000 mov r3, #0
8: e596600c ldr r6, [r6, #12]
c: e596500c ldr r5, [r6, #12]
10: e584309c str r3, [r4, #156] ; 0x9c
14: e286b064 add fp, r6, #100 ; 0x64
18: e5942094 ldr r2, [r4, #148] ; 0x94
1c: e892000a ldm r2, {r1, r3}
20: e592201c ldr r2, [r2, #28]
24: e0812602 add r2, r1, r2, lsl #12
28: e2436004 sub r6, r3, #4
2c: e2422001 sub r2, r2, #1
30: e5842084 str r2, [r4, #132] ; 0x84
34: e5950000 ldr r0, [r5]
38: e1a0e00f mov lr, pc
3c: e1a0f000 mov pc, r0
40: e1a0f00e mov pc, lr
llvm-3.0 gives near identical code (slight variation in instruction order):
00000000 :
0: e594608c ldr r6, [r4, #140] ; 0x8c
4: e3a03000 mov r3, #0
8: e596600c ldr r6, [r6, #12]
c: e596500c ldr r5, [r6, #12]
10: e584309c str r3, [r4, #156] ; 0x9c
14: e286b064 add fp, r6, #100 ; 0x64
18: e5942094 ldr r2, [r4, #148] ; 0x94
1c: e892000a ldm r2, {r1, r3}
20: e592201c ldr r2, [r2, #28]
24: e0812602 add r2, r1, r2, lsl #12
28: e2422001 sub r2, r2, #1
2c: e2436004 sub r6, r3, #4
30: e5842084 str r2, [r4, #132] ; 0x84
34: e5950000 ldr r0, [r5]
38: e1a0e00f mov lr, pc
3c: e1a0f000 mov pc, r0
40: e1a0f00e mov pc, lr
Unfortunately llvm-3.2 doesn't quite work. I get this error:
"inplace/bin/ghc-stage1" -static -H32m -O -package-name
ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/.
-ilibraries/ghc-prim/dist-install/build
-ilibraries/ghc-prim/dist-install/build/autogen
-Ilibraries/ghc-prim/dist-install/build
-Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
-optP-include
-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
-package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash
-XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples
-XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-db -rtsopts
-odir libraries/ghc-prim/dist-install/build -hidir
libraries/ghc-prim/dist-install/build -stubdir
libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o
libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
Call operand #8 has unhandled type i32UNREACHABLE executed at
CallingConvLower.cpp:129!
0 llc 0x08d19668
1 llc 0x08d19c04
2 libpthread.so.0 0x40055f38
3 ld-linux.so.2 0x400011b2
4 libc.so.6 0x401c91df gsignal + 79
5 libc.so.6 0x401cc825 abort + 373
6 llc 0x08d026cc
7 llc 0x087ee1bd
llvm::CCState::AnalyzeCallOperands(llvm::SmallVectorImplllvm::ISD::OutputArg
const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT,
llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 381
8 llc 0x0841e40c
llvm::ARMTargetLowering::LowerCall(llvm::TargetLowering::CallLoweringInfo&,
llvm::SmallVectorImplllvm::SDValue&) const + 492
9 llc 0x086a3d1f
llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&)
const + 6399
10 llc 0x086b3d0d
llvm::SelectionDAGBuilder::LowerCallTo(llvm::ImmutableCallSite,
llvm::SDValue, bool, llvm::MachineBasicBlock*) + 5341
11 llc 0x086bf029
llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 473
12 llc 0x086a7b46 llvm::SelectionDAGBuilder::visit(unsigned
int, llvm::User const&) + 390
13 llc 0x086cdcd8
llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 88
14 llc 0x086e8add
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, llvm::ilist_iterator, bool&) + 61
15 llc 0x086e97a5
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3093
16 llc 0x086eb1c1
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 961
17 llc 0x08892d72
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 194
18 llc 0x08ca2883
llvm::FPPassManager::runOnFunction(llvm::Function&) + 643
19 llc 0x08ca28ec
llvm::FPPassManager::runOnModule(llvm::Module&) + 76
20 llc 0x08ca257c
llvm::MPPassManager::runOnModule(llvm::Module&) + 540
21 llc 0x08ca6222 llvm::PassManagerImpl::run(llvm::Module&)
+ 162
22 llc 0x08ca6316 llvm::PassManager::run(llvm::Module&) + 38
23 llc 0x0818be9b main + 3707
24 libc.so.6 0x401b44d3 __libc_start_main + 243
25 llc 0x08199469
Stack dump:
0. Program arguments: /usr/local/bin/llc -O3 -relocation-model=static
/tmp/ghc19850_0/ghc19850_0.bc -o /tmp/ghc19850_0/ghc19850_0.lm_s
--enable-tbaa=true
1. Running pass 'Function Pass Manager' on module
'/tmp/ghc19850_0/ghc19850_0.bc'.
2. Running pass 'ARM Instruction Selection' on function
'@ghczmprim_GHCziPrimopWrappers_ztzhzh_slow'
/tmp/ghc19850_0/ghc19850_0.lm_s: openBinaryFile: does not exist (No such
file or directory)
make[1]: ***
[libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
make: *** [all] Error 2
(llvm-3.0 gave a vaguely similar error).
So, the best option looks like to use llvm-3.2 and fix anything that
isn't working.
Steve
On 16/01/13 09:28, Stephen Blackheath [to GHC-iPhone] wrote:
Nathan,
My GHC-iOS is based on HEAD from about November 2012.
The register that's used for base is defined in includes/stg/MachRegs.h
and is meant to be r4. This has never changed since the ARM work was
done. This is likely to be new breakage.
One possibility: There are certain versions of llvm that break with GHC
and ARM. llvm-3.0 is known to work. I believe this has been fixed since
(so new llvm-version should work), but I haven't confirmed it.
Looking at the cmm source for stg_returnToStackTop, the use of r0 looks
wrong because the comment says it's not using C arguments. r0-r3 are not
callee-saves and r0 is normally a C call argument and return value.
I just did a compile for Emdebian Linux (but haven't run any generated
code yet), and I'm getting almost the same as you:
00000000 :
0: e92d4010 push {r4, lr}
4: e24dd010 sub sp, sp, #16
8: e590108c ldr r1, [r0, #140] ; 0x8c
c: e3a04000 mov r4, #0
10: e591200c ldr r2, [r1, #12]
14: e592100c ldr r1, [r2, #12]
18: e580409c str r4, [r0, #156] ; 0x9c
1c: e2822064 add r2, r2, #100 ; 0x64
20: e5904094 ldr r4, [r0, #148] ; 0x94
24: e594c004 ldr ip, [r4, #4]
28: e594e000 ldr lr, [r4]
2c: e594401c ldr r4, [r4, #28]
30: e08e4604 add r4, lr, r4, lsl #12
34: e2444001 sub r4, r4, #1
38: e5804084 str r4, [r0, #132] ; 0x84
3c: e5914000 ldr r4, [r1]
40: e58d200c str r2, [sp, #12]
44: e24c2004 sub r2, ip, #4
48: e1a0e00f mov lr, pc
4c: e1a0f004 mov pc, r4
50: e28dd010 add sp, sp, #16
54: e8bd4010 pop {r4, lr}
58: e1a0f00e mov pc, lr
On the iPhone I get this:
_stg_returnToStackTop:
00000000 e5946064 ldr r6, [r4, #100]
00000004 e3a03000 mov r3, #0 @ 0x0
00000008 e596600c ldr r6, [r6, #12]
0000000c e596500c ldr r5, [r6, #12]
00000010 e5843074 str r3, [r4, #116]
00000014 e286b064 add fp, r6, #100 @ 0x64
00000018 e594306c ldr r3, [r4, #108]
0000001c e1c300d0 ldrd r0, [r3]
00000020 e593301c ldr r3, [r3, #28]
00000024 e0803603 add r3, r0, r3, lsl #12
00000028 e2416004 sub r6, r1, #4 @ 0x4
0000002c e2433001 sub r3, r3, #1 @ 0x1
00000030 e584305c str r3, [r4, #92]
00000034 e5953000 ldr r3, [r5]
00000038 e12fff33 blx r3
0000003c e12fff1e bx lr
A comparison strongly supports your idea that it's using r0 when it
should be using r4.
I am going to try some different versions of llvm.
Steve
On 16/01/13 06:59, Nathan Hüsken wrote:
Hey,
I am currently trying to get a ghc cross compiler for android linux to
work.
I am basing this on the development version (HEAD). I succeeded building
the compiler. Unfortunately, the executables produced by the compiler
segfault on my android device.
If I do an unregisterised build, it works!
Since the iphone is also an arm platform, I was hoping someone here
could help me a little bit.
I investigate the problem a little bit (see this thread:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000013.html) and
I am guessing (I am no expert) that it is an arm problem, not android.
It seems like the wrong register is used for base (r0 instead of r4).
* On which ghc version is the iphone fork based?
* Are there any arm fixes in the iphone fork that could be related to
this?
Thank you!
Nathan
_______________________________________________
iPhone mailing list
iPhone@haskell.org
http://www.haskell.org/mailman/listinfo/iphone
