Re: Status and future of the LLVM backend
Ben Gamari wrote: I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. Have a look when you get a chance. To summarize, * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework when the `$def` symbols are marked as internal * ARM is broken (again) due to a bug in the GHC calling convention implementation; an LLVM fix is waiting to be merged * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 support will likely need to wait until 7.12 * Austin's LLVM packaging proposal seems very much like the right way forward * Anticipating this proposal, I have started collecting [2] optimization passes I've recently been working on amd64-linux to armhf-linux and aarch64-linux cross-compilers. In addition to the above: * LLVM 3.6 that Ben mentions above has not yet been released and is still a work in progress. A commit to the LLVM tree made as recently as December 17th means LLVM head no longer compiles LLVM IR code generated by GHC (metadata issue mentioned in #9920). * LLVM uses C/C++ asserts liberally and these asserts get compiled out during optimised builds (eg for Linux distributions). The removal of these asserts results in llvm binaries that *silently* generate incorrect binaries (see #9920 which is Ben's second bullet point above). For instance, I built an amd64-linux to aarch64-linux cross compiler which generated executables that crashed immediately. When I switched to a debug version of LLVM, LLVM's opt and llc suddenly started showing assertion failures all over. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Samstag, den 06.12.2014, 16:19 +0100 schrieb Joachim Breitner: nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 and will try with these. Once I get it to compile I’ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4. and the build went further, I now have snip Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951 Ben, can you help me out here? I've been unable to reproduce this issue in my environment. The build succeeded using your packaging on my Odroid XU running Debian Jessie. Unfortunately every subsequent build seems to fail with this build system issue, ... inplace/bin/ghc-cabal configure libraries/integer-gmp dist-install --with-ghc=/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/ghc-stage1 --with-ghc-pkg=/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/gh c-pkg --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour=/usr/bin/HsColour --configure-option=CFLAGS= -fno-stack-protector--configure-option=L DFLAGS=--configure-option=CPPFLAGS=--gcc-options= -fno-stack-protector--with-gcc=/usr/bin/gcc --with-ld=/usr/bin/ld --configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/bin/ar -- with-ranlib=/usr/bin/ranlib --with-alex=/home/ben/.cabal/bin/alex --with-happy=/home/ben/.cabal/bin/happy Configuring integer-gmp-0.5.1.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc configure: error: cannot run /bin/bash ./config.sub libraries/integer-gmp/ghc.mk:4: recipe for target 'libraries/integer-gmp/dist-install/package-data.mk' failed It seems that this is likely due to dh_autoreconf which overwrites all config.subs with /usr/share/misc/config.sub. It's totally unclear to me how the first build succeeded, however. Have you seen this in the past? Cheers, - Ben pgpIJO5uKVIVB.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Hi, Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari: Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951 Ben, can you help me out here? I've been unable to reproduce this issue in my environment. The build succeeded using your packaging on my Odroid XU running Debian Jessie. Weird. Can you try creating a sid chroot and building it in there? I managed to finish the build with this patch attached: Index: ghc-7.8.20141119/includes/stg/SMP.h === --- ghc-7.8.20141119.orig/includes/stg/SMP.h +++ ghc-7.8.20141119/includes/stg/SMP.h @@ -14,13 +14,13 @@ #ifndef SMP_H #define SMP_H -#if defined(THREADED_RTS) - #if arm_HOST_ARCH defined(arm_HOST_ARCH_PRE_ARMv6) void arm_atomic_spin_lock(void); void arm_atomic_spin_unlock(void); #endif +#if defined(THREADED_RTS) + /* Atomic operations - */ Index: ghc-7.8.20141119/rts/OldARMAtomic.c === --- ghc-7.8.20141119.orig/rts/OldARMAtomic.c +++ ghc-7.8.20141119/rts/OldARMAtomic.c @@ -14,8 +14,6 @@ #include sched.h #endif -#if defined(THREADED_RTS) - #if arm_HOST_ARCH defined(arm_HOST_ARCH_PRE_ARMv6) static volatile int atomic_spin = 0; @@ -51,6 +49,3 @@ void arm_atomic_spin_unlock() } #endif /* arm_HOST_ARCH defined(arm_HOST_ARCH_PRE_ARMv6) */ - -#endif /* defined(THREADED_RTS) */ - So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not? Unfortunately every subsequent build seems to fail with this build system issue, ... inplace/bin/ghc-cabal configure libraries/integer-gmp dist-install --with-ghc=/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/ghc-stage1 --with-ghc-pkg=/mnt/ext/ghc/debian/ghc-7.8.20141119/inplace/bin/gh c-pkg --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour=/usr/bin/HsColour --configure-option=CFLAGS= -fno-stack-protector--configure-option=L DFLAGS=--configure-option=CPPFLAGS=--gcc-options= -fno-stack-protector--with-gcc=/usr/bin/gcc --with-ld=/usr/bin/ld --configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/bin/ar -- with-ranlib=/usr/bin/ranlib --with-alex=/home/ben/.cabal/bin/alex --with-happy=/home/ben/.cabal/bin/happy Configuring integer-gmp-0.5.1.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc configure: error: cannot run /bin/bash ./config.sub libraries/integer-gmp/ghc.mk:4: recipe for target 'libraries/integer-gmp/dist-install/package-data.mk' failed It seems that this is likely due to dh_autoreconf which overwrites all config.subs with /usr/share/misc/config.sub. It's totally unclear to me how the first build succeeded, however. Have you seen this in the past? Yes, likely a bug in dh_autoreconf that does not handle rebuilds well (or a bug in how we use it). Until that is fixed I use rm -rf ghc-7.8.20141119 dpkg-source -x ghc_7.8.20141119-6.dsc cd ghc-7.8.20141119/ schroot -r -c ghc -- debuild -uc -us to get a clean state again. I’ll have to look into that eventually. Autoconf is a mess. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
On 12/ 8/14 03:49 PM, Joachim Breitner wrote: So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not? Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1]. I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware... Hope that helps, Karel [1]: https://wiki.debian.org/ArmEabiPort [2]: https://wiki.debian.org/ArmHardFloatPort ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Hi, Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas: On 12/ 8/14 03:49 PM, Joachim Breitner wrote: So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not? Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1]. I’m currently working on what Debian calls armel, so [1]. We’ll also have to get it working on armhf (which seems to be [2]). Maybe things are different there I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware... Yes, that makes sense. In that case, the use of the slow spinlock implementation is correct, and GHC’s build system needs to be fixed to work in that situation, right? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
On 12/ 8/14 04:44 PM, Joachim Breitner wrote: Hi, Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas: On 12/ 8/14 03:49 PM, Joachim Breitner wrote: So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not? Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1]. I’m currently working on what Debian calls armel, so [1]. We’ll also have to get it working on armhf (which seems to be [2]). Maybe things are different there Yes, but [2] is what Ubuntu is using and it was all right in the past at least modulo ghci/linker support which Ben was fixing. I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware... Yes, that makes sense. In that case, the use of the slow spinlock implementation is correct, and GHC’s build system needs to be fixed to work in that situation, right? Yes, probably, I've not followed whole thread of discussion unfortunately. BTW, IIRC this is configure/aclocal.m4 check what's the target ARM platrform capability, I'm a little bit surprised this is not working for you now. Also please make sure generated platform details are correct in settings file... Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Joachim Breitner nome...@debian.org writes: Hi, Am Montag, den 08.12.2014, 08:20 -0500 schrieb Ben Gamari: Again Google finds me a bug, but this time one that has no fix associated with it: https://ghc.haskell.org/trac/ghc/ticket/8951 Ben, can you help me out here? I've been unable to reproduce this issue in my environment. The build succeeded using your packaging on my Odroid XU running Debian Jessie. Weird. Can you try creating a sid chroot and building it in there? I managed to finish the build with this patch attached: Great! So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not? Could you confirm that arm_HOST_ARCH_PRE_ARMv6 is actually defined in mk/config.h? If so we should try to figure out why. The architecture is determined by autoconf. Perhaps you could attach config.log? It seems that this is likely due to dh_autoreconf which overwrites all config.subs with /usr/share/misc/config.sub. It's totally unclear to me how the first build succeeded, however. Have you seen this in the past? Yes, likely a bug in dh_autoreconf that does not handle rebuilds well (or a bug in how we use it). Hmm, alright. Why exactly do we overwrite config.sub and config.guess? I guess we are trying to ensure that the build systems in libraries/* are generated by the system's autoconf (taking the place of `boot`)? Is there a reason we can't just use autoreconf as `boot` does? Cheers, - Ben pgp2Z1Ygbrp2f.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Montag, den 08.12.2014, 16:34 +0100 schrieb Karel Gardas: On 12/ 8/14 03:49 PM, Joachim Breitner wrote: So what does that tell us? Maybe Peter can help us: Is it normal for a Debian system to pretend that its a pre-v6 ARM, even if the actual hardware is not? Sorry to get into this, but are you using EABI[1] port of HardFloat[2] port? Wheezy claims to support[2], the release before this was[1]. I’m currently working on what Debian calls armel, so [1]. We’ll also have to get it working on armhf (which seems to be [2]). Maybe things are different there Indeed I think Karel has identified the difference in that case. I'm on armhf. Thanks Karel! I didn't realize that armel supported such old hardware. I'm not sure what you use so I'm asking, anyway, if you use[1], then it's normal it pretends it's pre-ARMv6. I.e. this is similar to i386 debian port in the past which was running happily on i686 but pretend to be i386 to be compatible with all the supported hardware... Yes, that makes sense. In that case, the use of the slow spinlock implementation is correct, and GHC’s build system needs to be fixed to work in that situation, right? Indeed. It seems that armel is indeed supposed to support down to ARMv5 for which we'll need the spinlock fallback. Cheers, - Ben pgpF_iIKteVvc.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Hi, Am Freitag, den 05.12.2014, 20:25 +0100 schrieb Joachim Breitner: So, less elegantly, I’m now trying @@ -487,7 +487,7 @@ AC_DEFUN([FP_SETTINGS], fi fi SettingsCCompilerFlags=$CONF_CC_OPTS_STAGE2 -SettingsCCompilerLinkFlags=$CONF_GCC_LINKER_OPTS_STAGE2 +SettingsCCompilerLinkFlags=$CONF_GCC_LINKER_OPTS_STAGE2 -fuse-ld=gold SettingsLdFlags=$CONF_LD_LINKER_OPTS_STAGE2 AC_SUBST(SettingsCCompilerCommand) AC_SUBST(SettingsHaskellCPPCommand) great, this works, and the build proceeds up to calling dll-split, and that does not crash as it did before. But it gives this error message: inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell DynFlags Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike 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 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet 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[2]: *** [compiler/stage2/dll-split.stamp] Error 1 any idea what might be causing this? I started the build from a fresh checkout. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Hi, Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner: any idea what might be causing this? I started the build from a fresh checkout. nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 and will try with these. Once I get it to compile I’ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4. Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Samstag, den 06.12.2014, 15:59 +0100 schrieb Joachim Breitner: any idea what might be causing this? I started the build from a fresh checkout. nevermind, I found https://ghc.haskell.org/trac/ghc/ticket/9552 and https://git.haskell.org/ghc.git/patch/2a8ea4745d6ff79d6ce17961a64d9013243fc3c6 and will try with these. Once I get it to compile I’ll give a complete list of patches that I had to backport, with the recommendation to include them in GHC 7.8.4. Excellent! Thanks for doing this. I wish I had been able to provide more guidance but the end of the semester has been a bit crazy. Cheers, - Ben pgpWmmHk3aXNk.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Hi, Am Donnerstag, den 04.12.2014, 23:37 +0100 schrieb Joachim Breitner: The problem is that in order to find out which linker is used, ghc calls /usr/bin/gcc -Wl,-version without passing the options from -optl, so the -fuse-ld=gold is not used in this step. I’m a bit confused, because the code in getLinkerInfo' looks like it should be passing them... ah, but only on HEAD, not in 7.8... and git blame tells me that I probably want to apply this patch: commit e7b414a3cc0e27049f2608f5e0a00c47146cc46d Author: Sebastian Dröge sebast...@centricular.com Date: Tue Nov 18 12:40:20 2014 -0600 now gold is used, but if I set this in SRC_HC_OPTS, it is also passed to the bootstrapping compiler, which does not work with gold. So it seems I want to modify the C compiler link flags settings. I tried to achieve this using Index: ghc-7.8.20141119/aclocal.m4 === --- ghc-7.8.20141119.orig/aclocal.m4 +++ ghc-7.8.20141119/aclocal.m4 @@ -553,6 +553,10 @@ AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], $3=$$3 -D_HPUX_SOURCE $5=$$5 -D_HPUX_SOURCE ;; +arm*) +# On arm, link using gold +$3=$$3 -fuse-ld=gold +;; esac # If gcc knows about the stack protector, turn it off. but this made the settings reach parts of the build system where I did not want them, and for example tips over configuring terminfo-0.4.0.0...: checking for setupterm in -ltinfo... yes configure: creating ./config.status config.status: creating terminfo.buildinfo configure: WARNING: unrecognized options: --with-compiler, --with-gcc ghc-cabal: Missing dependency on a foreign library: * Missing C library: tinfo This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. because --gcc-options=-fuse-ld=gold is being passed to ./configure. Now idea why that confuses ghc-cabal. Unfortunately, cabal is not very verbose and does not tell me why and how the test C program failed to compile but strace helps. And we are back at /usr/bin/ld.gold: --hash-size=31: unknown option But I’m not sure where this comes from. So, less elegantly, I’m now trying @@ -487,7 +487,7 @@ AC_DEFUN([FP_SETTINGS], fi fi SettingsCCompilerFlags=$CONF_CC_OPTS_STAGE2 -SettingsCCompilerLinkFlags=$CONF_GCC_LINKER_OPTS_STAGE2 +SettingsCCompilerLinkFlags=$CONF_GCC_LINKER_OPTS_STAGE2 -fuse-ld=gold SettingsLdFlags=$CONF_LD_LINKER_OPTS_STAGE2 AC_SUBST(SettingsCCompilerCommand) AC_SUBST(SettingsHaskellCPPCommand) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Hi, Am Montag, den 01.12.2014, 09:42 +0100 schrieb Joachim Breitner: Am Sonntag, den 30.11.2014, 18:49 -0500 schrieb Ben Gamari: Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari: What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea? Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk. Cleaner maybe, but it was not picked up either. Or maybe we are looking at a different issue, not solved by using ld.gold? I suspect that it this is the gold issue. I should have looked at your command line a bit more carefully; I suspect you want SRC_HC_OPTS += -optl-B/usr/bin/ld.gold Hopefully this will do it; at least the option appears to make it to the right phase now. Trying it right now... no success, same error: https://buildd.debian.org/status/fetch.php?pkg=ghcarch=armhfver=7.8.20141119-6stamp=1417438953file=log Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Joachim Breitner m...@joachim-breitner.de writes: Hi Ben, Am Freitag, den 28.11.2014, 18:27 -0500 schrieb Ben Gamari: I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5. After I tightened the dependencies to use llvm-3.4, it failed with dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux) Indeed this looks like ld.bfd is being used. I then followed your advice from somewhere else and passed --with-ld=ld.gold to ./configure, but with the same effect: Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does. Unfortunately it's also a bit more subtle than this; it's very likely that the ghc you are bootstrapping from contains relocations that aren't supported by gold. For this reason you'll likely need to build some of the utilities with `ld.bfd` the continue the build with `ld.gold`. The above script implements this fairly reliably. Cheers, - Ben [1] https://gist.github.com/bgamari/9399430 pgpNowSMepbYK.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
[Resent, as ghc-dev does not like my other address. Sorry Ben] Hi, Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari: thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5. After I tightened the dependencies to use llvm-3.4, it failed with dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux) Indeed this looks like ld.bfd is being used. hmm, that’s annoying that --with-ld does not do the right thing. Is there a bug reported about this? I then followed your advice from somewhere else and passed --with-ld=ld.gold to ./configure, but with the same effect: Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does. hmm, I’ll need to port that somehow to how the Debian package is built. But it seems to be cleaner to use the -B flag to gcc, available at least on Debian, according to https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html. What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea? Unfortunately it's also a bit more subtle than this; it's very likely that the ghc you are bootstrapping from contains relocations that aren't supported by gold. For this reason you'll likely need to build some of the utilities with `ld.bfd` the continue the build with `ld.gold`. The above script implements this fairly reliably. What would be the symptoms of that problem? Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Joachim Breitner m...@joachim-breitner.de writes: [Resent, as ghc-dev does not like my other address. Sorry Ben] Hi, Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari: thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. First, because it picked llvm-3.5. After I tightened the dependencies to use llvm-3.4, it failed with dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux) Indeed this looks like ld.bfd is being used. hmm, that’s annoying that --with-ld does not do the right thing. Is there a bug reported about this? Not that I know of. It would be good if it did the right thing although I'm afraid that the gold issue described below means that it wouldn't make much difference in practice; I don't think we want to be in the business of building in hacks working around linker quirks into our build system. I then followed your advice from somewhere else and passed --with-ld=ld.gold to ./configure, but with the same effect: Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does. hmm, I’ll need to port that somehow to how the Debian package is built. But it seems to be cleaner to use the -B flag to gcc, available at least on Debian, according to https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html. What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea? Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk. Unfortunately it's also a bit more subtle than this; it's very likely that the ghc you are bootstrapping from contains relocations that aren't supported by gold. For this reason you'll likely need to build some of the utilities with `ld.bfd` the continue the build with `ld.gold`. The above script implements this fairly reliably. What would be the symptoms of that problem? You'll see an error message of the form, /usr/bin/ld.gold: error: /usr/lib/ghc/libHSrts.a(GetTime.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC I'm tempted to just try implementing this relocation type but sadly these sorts of patches always take longer to get right than I expect. Cheers, - Ben pgpR7JVVHNiE9.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Hi, Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari: I then followed your advice from somewhere else and passed --with-ld=ld.gold to ./configure, but with the same effect: Unfortunately I don't think this will be sufficient. I believe this will only set the `LD` variable in the build system, which as far qas I know is never used. We always call gcc to do our linking for us; gcc will in turn just use whatever `ld` it finds in `PATH`. For this reason I have resorted to simply adding a directory containing a symlink to `ld.gold` to `PATH`. This is what this script[1] does. hmm, I’ll need to port that somehow to how the Debian package is built. But it seems to be cleaner to use the -B flag to gcc, available at least on Debian, according to https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html. What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea? Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk. Cleaner maybe, but it was not picked up either. Or maybe we are looking at a different issue, not solved by using ld.gold? inplace/bin/ghc-stage1 -o utils/dll-split/dist-install/build/tmp/dll-split -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -lffi -optl-pthread -optc-mlong-calls -optc-B/usr/bin/ld.gold -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.2 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -odir utils/dll-split/dist-install/build -hidir utils/dll-split/dist-install/build -stubdir utils/dll-split/dist-install/build -optl-L'/«PKGBUILDDIR»/libraries/filepath/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/containers/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/deepseq/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/array/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/base/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/integer-gmp/dist-install/build' -optl-L'/«PKGBUILDDIR»/libraries/ghc-prim/dist-install/build' -optl-L'/«PKGBUILDDIR»/rts/dist/build' -optl-lgmp -optl-lm -optl-lrt -optl-ldl -optl-lffi -fPIC -dynamic -H32m -O -lffi -optl-pthread -optc-mlong-calls -optc-B/usr/bin/ld.gold -hide-all-packages -i -iutils/dll-split/. -iutils/dll-split/dist-install/build -iutils/dll-split/dist-install/build/autogen -Iutils/dll-split/dist-install/build -Iutils/dll-split/dist-install/build/autogen -optP-include -optPutils/dll-split/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.2 -package containers-0.5.5.1 -package filepath-1.3.0.2 -XHaskell98 -no-user-package-db -rtsopts -fno-use-rpaths -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../filepath-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../containers-0.5.5.1' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../deepseq-1.3.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../array-0.5.0.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../base-4.7.0.2' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../integer-gmp-0.5.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../ghc-prim-0.3.1.0' -optl-Wl,-rpath -optl-Wl,'$ORIGIN/../rts-1.0' -optl-Wl,-zorigin utils/dll-split/dist-install/build/Main.dyn_o [..] cp -p utils/dll-split/dist-install/build/tmp/dll-split inplace/lib/bin/dll-split dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.3.20141119 for arm_unknown_linux) https://buildd.debian.org/status/fetch.php?pkg=ghcarch=armelver=7.8.20141119-5stamp=1417383951 Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Status and future of the LLVM backend
Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Sonntag, den 30.11.2014, 16:48 -0500 schrieb Ben Gamari: What would be a reliable way to make the build system pass -B/usr/bin/ld.gold to gcc? Is SRC_HC_OPTS += -optc-B/usr/bin/ld.gold in mk/build.mk a good idea? Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk. Cleaner maybe, but it was not picked up either. Or maybe we are looking at a different issue, not solved by using ld.gold? I suspect that it this is the gold issue. I should have looked at your command line a bit more carefully; I suspect you want SRC_HC_OPTS += -optl-B/usr/bin/ld.gold Hopefully this will do it; at least the option appears to make it to the right phase now. Is the Debian packaging tracked in version control somewhere? All I can find is the packaging tarball [1]. Cheers, - Ben [1] https://packages.debian.org/sid/ghc pgpYO6qC1_JIX.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Status and future of the LLVM backend
I've written down some thoughts on the current status and future direction of the LLVM backend here [1]. Have a look when you get a chance. To summarize, * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework when the `$def` symbols are marked as internal * ARM is broken (again) due to a bug in the GHC calling convention implementation; an LLVM fix is waiting to be merged * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6 support will likely need to wait until 7.12 * Austin's LLVM packaging proposal seems very much like the right way forward * Anticipating this proposal, I have started collecting [2] optimization passes Cheers, - Ben [1]: http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html [2]: https://github.com/bgamari/ghc-llvm-analyses pgpwIJUikD3pM.pgp Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
