aarch64 support in ghc
Hello.
Please, introduce the aarch64 support in ghc. The latest LLVM seems to support the aarch64 already.
Thanks in advance.
Regards, Jaromir.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown/Multiple |
Activity
mentioned in issue #7623 (closed)
added Tfeature request Trac import labels
CCing myself.
To kick things off, here are links to a couple of relevant docs from ARM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.genc010197a/index.html
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056b/IHI0056B_aaelf64.pdf
The first is the instruction set reference, the second is ELF ABI reference.
Trac metadata
Trac field Value CC → jdulaney@fedoraproject.org Trac metadata
Trac field Value CC jdulaney@fedoraproject.org → jdulaney@fedoraproject.org, juhp@community.haskell.org I'm not against working on this but first we need to have properly working x64-linux -> arm-linux cross-compiling tool chain on place which I'm not sure if it's working or not. So I mark this as blocking on #7623 (closed) for now.
Trac metadata
Trac field Value BlockedBy → #7623 (closed) I'm using linaro here for this, but the question is not about C cross-compilation tool-chain but about GHC LLVM-based cross-compilation support. If this is ready and working at least for ARM (as the most used cross-compilation target), then let's start working on it. If not, then let's first solve this homework...
changed milestone to %7.10.1
assigned to @kgardas
for llvm or NCG? for NCG, its kinda gated on first doing some NCG cleanup, (because theres a lot of copy pasta logic across the current NCG backends, and improving the engineering niceness of NCG will make such easier).
please feel welcome to hack out a prototype if you have the time, but please keep in mind that it may be easier after first cleaning up and refactoring NCG.
I *hope* to have the time to start hacking on that refactoring end of january onwards, though i hope other people collab on it too.
that said, if you mean LLVM specifically, go crazy! I think there may be some experimental support on GHC-IOS, but I could be wrong
I'm following the same way like Stephen/David/me did ARM in the past: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting NCG way makes sense once you do have LLVM working, then you can try -fasm on smallest examples and do it step-by-step with increased example complexity.
Replying to [ticket:7942#comment:77995 carter]:
sounds reasonable. Will the arm 32 bit ghc calling convention make sense for AArch64? We may need to get a patch into llvm before having a distinct aarch64 abi. (and we should probably do some pretty thorough benchmarking before picking any such ABI)
Not at all! aarch64 abi is completely different with completely different (or better nicely extended) register stack! So basically aarch64 is completely different beast than arm and I'm also doing it separately instead of extending current arm support.
W.r.t. benchmarking, I've also had such discussion with David few year ago, but then Stephen comes with work done so no benchmarking was done. The point is to find some sweet-spot inbetween using callee-saved regs for STG regs pinning and between leaving them for LLVM business usage...
Anyway, as I said, we're not there yet, although I already do have some code here. The problem is LLVM/AArch64 is not there yet as you can see from my bug report here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-January/069248.html and that is just unregisterised build...
Replying to [ticket:7942#comment:78026 carter]:
@karel, unregisterized builds use GCC specific C code, in which case you'll have to use GCC.
GCC 4.8 and newer, when built with multi target support, seems to have aarch 64 support.
clang/llvm wont work.
cheers -Carter
Carter, this is misunderstanding IMHO. I'm not dealing with unregisterised via C, but instead with unregisterised via LLVM build here. Please read the GHC/LLVM porting document I linked above for more information.
@carter: but -fvia-C is no longer supported, at least, https://ghc.haskell.org/trac/ghc/wiki/Building/Porting suggests that. So LLVM is the only way for AArch64 as we do not have NCG ready for this platform...
mentioned in issue #8664 (closed)
Trac metadata
Trac field Value BlockedBy #7623 (closed) → #7623 (closed), #8664 (closed) Good! So this LLVM bug above shows only on PrimoptWrappers and I've been able to compile this file without -fllvm as Carter points out above. So here is bindist's HelloWorld running on AArch64/ARM64 platform:
root@localhost:~# ./HelloWorld Hello world!root@localhost:~# file HelloWorld HelloWorld: ELF 64-bit LSB executable, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.7.0, BuildID[sha1]=0x5301662c82ccd3fe7c3f1486ac10d0f13b2f54c9, not stripped root@localhost:~# uname -m aarch64 root@localhost:~#unassigned @kgardas
I've been working with Karel Gardas (kgardas) to get this going, and I've now completed an unregisterised GHC bootstrap on Ubuntu arm64. I started by cross-building GHC 7.8 using variations on Karel's patch set, and then bodged together a GHC 7.6 build (since that's what we're shipping on other architectures) bootstrapping off that. This all now appears to be working fine and I should be able to get binaries into our archive in the next few days.
I'm attaching a patch (made against the ghc-7.8 branch); most of it is Karel's from https://ghcarm.wordpress.com/2014/01/18/unregisterised-ghc-head-build-for-arm64-platform/, I've just tweaked it a bit given that I had the advantage of access to real hardware. Some of this may be unnecessary for an unregisterised build, but it doesn't hurt. It would be great if somebody could review and apply it, since it's a lot easier to get started on more advanced things like LLVM or NCG support if you don't have to do the time-consuming bootstrap yourself. Please note that you also need to update the embedded copy of libffi in
libffi-tarballs/to at least version 3.0.12.Karel's initial patch caused
GHC_CONVERT_CPUto returnarm64. I changed this toaarch64, since the return value ofGHC_CONVERT_CPUis used to construct the--hostoption for configure scripts and thus it needs to be valid as the first part of a GNU config triplet. I left the Haskell-level architecture name asArchARM64, since that style is more common as a user-facing name for the architecture: for example, the Linux kernel returnsarm64in itsunameoutput.Attached file
ghc-aarch64.patch(download).add aarch64 support
Trac metadata
Trac field Value CC jdulaney@fedoraproject.org, juhp@community.haskell.org → cjwatson@ubuntu.com, jdulaney@fedoraproject.org, juhp@community.haskell.org This has been merged in c29bf984 - thank you Colin!
Trac metadata
Trac field Value Version 7.6.3 → Resolution Unresolved → ResolvedFixed BlockedBy #7623 (closed), #8664 (closed) → Related → #7623 (closed), #8664 (closed) Hi folks, I'm trying to use this to get ARM64 compilation working for iOS and am running into this:
"inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DNOSMP -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-O2 -optc-fomit-frame-pointer -optc-DRtsWay=\"rts_v\" -optc-w -static -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/StgCRun.c -o rts/dist/build/StgCRun.o rts/StgCRun.c:789:24: error: index must be an integer in range [-256, 255]. STG_RETURN ":\n\t" ^ <inline asm>:13:16: note: instantiated into assembly here ldr lr, [sp], #16384 ^ 1 error generated.(I made a couple of other changes, changing bx to br and references to ip0 and ip1 to x16 and x17, to get things this far)
Does that make sense to anyone? Thanks!
OK, so if I replace the offending call with
"ldr lr, [sp]\n\t" "add sp, sp, %3\n\t"(which I believe should be functionally equivalent)
I can compile, but then get a crash running on the device here:
HelloHaskell`StgRun: 0x1004cea34: stp x28, x27, [sp, #-96]! 0x1004cea38: stp x26, x25, [sp, #16] 0x1004cea3c: stp x24, x23, [sp, #32] 0x1004cea40: stp x22, x21, [sp, #48] 0x1004cea44: stp x20, x19, [sp, #64] 0x1004cea48: stp fp, lr, [sp, #80] 0x1004cea4c: stp x19, x20, [sp, #-16]! 0x1004cea50: stp x21, x22, [sp, #-16]! 0x1004cea54: stp x23, x24, [sp, #-16]! 0x1004cea58: stp x25, x26, [sp, #-16]! 0x1004cea5c: stp x27, x28, [sp, #-16]! 0x1004cea60: stp x16, x17, [sp, #-16]! 0x1004cea64: str lr, [sp, #-8]! 0x1004cea68: str lr, [sp, #16384] <------------EXC_BAD_ACCESS (code=259, address=0x16fdcf7a8) 0x1004cea6c: mov x19, x1 0x1004cea70: br x0So basically you try to cross-compile using registerised GHC? If so, then I'm afraid nobody hacked LLVM to support GHC specific calling convention on ARM64 yet! If unregisterised, then you IMHO you should not be in this part of code which is IMHO just for registerised builds. Also if you attempt unregisterised, I would advice to use gcc and not llvm i.e. -fvia-C and not -fllvm for the start.
One general note: the code in StgCRun written for ARM64 was probably written by me (I've provided the patch to Colin). So if this is this code, then please be assured that this code *never* has run on ARM64. It was written just from reading doc and as a first attempt to add support for registerised ARM64. At that time I've finished with this since I had not machine, ARM's foundation model was really slow and LLVM project was just before big merge from ARM's own AArch64 and Apple's own ARM64 LLVM backends together. Although the situation now looks way much better, at least both LLVM backends were merged together and even some hardware appears this all still means that if nobody has done it yet, then someone needs to do quite a lot. When I've been working on ARM port with Stephen, David helped me a lot and we wrote following LLVM/porting guide. I would recommend to read it: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/GHC_LLVMPorting
(another +1 for NCG for arm and arm64! :-)
Likely I should open a new ticket, but I am having trouble with installing ghc-7.8.3 plus above patch on Fedora 21 ARM64 (aarch64).
"inplace/bin/ghc-cabal" copy libraries/haskell2010 dist-install "strip" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' 'v dyn ' Installing library in /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/haskell2010-1.1.2.0 "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg" --force --global-package-db "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/package.conf.d" update rts/dist/package.conf.install Reading package info from "rts/dist/package.conf.install" ... done. rts-1.0: Warning: library-dirs: /usr/lib64/ghc-7.8.3/rts-1.0 doesn't exist or isn't a directory rts-1.0: Warning: include-dirs: /usr/lib64/ghc-7.8.3/include doesn't exist or isn't a directory rts-1.0: cannot find any of ["libHSrts.a","libHSrts.p_a","libHSrts-ghc7.8.3.so","libHSrts-ghc7.8.3.dylib","HSrts-ghc7.8.3.dll"] on library path (ignoring) "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg : "" Registering ghc-prim-0.3.1.0... "inplace/bin/ghc-cabal" register libraries/integer-gmp dist-install "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg" "/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3" '/builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64' '/usr' '/usr/lib64/ghc-7.8.3' '/usr/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /builddir/build/BUILDROOT/ghc-7.8.3-38.fc22.aarch64/usr/lib64/ghc-7.8.3/bin/ghc-pkg : "" ghc-cabal: Installed package ID not registered: "ghc-prim-0.3.1.0-inplace" ghc.mk:901: recipe for target 'install_packages' failed Makefile:64: recipe for target 'install' failed make[1]: *** [install_packages] Error 1 make: *** [install] Error 2The problem seems to be that the installed (dynlinked) ghc-pkg does no output anything! (eg "ghc-pkg --version" returns "", same for --help.)
When I try the built binaries I find that ghc-7.8.3/utils/ghc-pkg/dist/build/tmp/ghc-pkg (which is statically linked) works normally (ie it outputs --help and --version) whereas
DESTDIR/libdir/ghc-7.8.3/bin/ghc-pkg gives no output on stdout!Maybe I should try installing statically linked ghc and see if that makes difference.
Trac metadata
Trac field Value CC cjwatson@ubuntu.com, jdulaney@fedoraproject.org, juhp@community.haskell.org → cjwatson@ubuntu.com, jdulaney@fedoraproject.org, petersen@fedoraproject.org Replying to [ticket:7942#comment:88956]:
Maybe I should try installing statically linked ghc and see if that makes difference.
Unfortunately the DYNAMIC_GHC_PROGRAMS=NO build fails already in the build phase:
: cat utils/hpc/hpc.wrapper >> inplace/bin/hpc chmod +x inplace/bin/hpc Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed make[1]: *** [compiler/stage2/dll-split.stamp] Error 1 make[1]: *** Waiting for unfinished jobs.... Makefile:64: recipe for target 'all' failed make: *** [all] Error 2
