Re: Performance regression on typechecking type families?
I personally have run into exponential compile times with type families. Unfortunately I have not had the time yet to reduce my test case to something tractable. Janek Dnia sobota, 29 listopada 2014, Dr. ERDI Gergo napisał: Hi, Prompted by this question: http://stackoverflow.com/questions/26538595/more-efficient-type-level-compu tations-using-type-families I wrote some code today using closed type families and datakinds. Also, as a baseline, I typechecked the code using open type families from the original question. The two files are here: https://gist.github.com/gergoerdi/727f028e4c1ed158ac9a https://gist.github.com/gergoerdi/f96d1a9a58f5e3dccc18 On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking time, respectively! Is this some known regression, something surprising, or is 'perf' simply not the right build flavour for this kind of comparison? Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ 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: Failing tests: literals T5681 annotations
Hi,
I’m still seeing this failure:
Compile failed (status 256) errors were:
/tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
/tmp/ghc16123_0/ghc16123_5.s:26:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_zdwwork_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:46:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_work_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:66:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main1_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:86:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:106:0:
Error: can't resolve `.rodata' {.rodata section} - `Main_main2_info$def'
{.text section}
/tmp/ghc16123_0/ghc16123_5.s:126:0:
Error: can't resolve `.rodata' {.rodata section} - `ZCMain_main_info$def'
{.text section}
*** unexpected failure for T5681(optllvm)
https://s3.amazonaws.com/archive.travis-ci.org/jobs/42557559/log.txt
Any ideas?
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: [commit: ghc] master: compiler: fix trac issue #8815 (780b061)
Hi, just a quick note: This commit message is rather unhelpful. In this case it is not a big deal (the patch is quite self-explanatory), but I recommend you to manually clean up arc-generated commit messages before pushing. Also remember when creating a Phab DR that whatever you put in the summary will be part of the default commit message. Greetings, Joachim (who does more complaining than actual contributing these days...) Am Sonntag, den 30.11.2014, 19:17 + schrieb g...@git.haskell.org: Repository : ssh://g...@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6/ghc --- commit 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6 Author: Sivaram Balakrishnan sivaram1...@gmail.com Date: Sun Nov 30 13:05:56 2014 -0600 compiler: fix trac issue #8815 Summary: This patch changes the error message as suggested in trac issue #8815 comments. Reviewers: jstolarek, austin Reviewed By: jstolarek, austin Subscribers: jstolarek, thomie, carter Differential Revision: https://phabricator.haskell.org/D533 GHC Trac Issues: #8815 --- 780b061ce2aea4722d1a5d0e46fd4ed8ee2641d6 compiler/typecheck/TcPat.lhs | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/compiler/typecheck/TcPat.lhs b/compiler/typecheck/TcPat.lhs index 3b7b5df..58e8bae 100644 --- a/compiler/typecheck/TcPat.lhs +++ b/compiler/typecheck/TcPat.lhs @@ -796,7 +796,8 @@ tcDataConPat penv (L con_span con_name) data_con pat_ty arg_pats thing_inside ; gadts_on- xoptM Opt_GADTs ; families_on - xoptM Opt_TypeFamilies ; checkTc (no_equalities || gadts_on || families_on) - (ptext (sLit A pattern match on a GADT requires GADTs or TypeFamilies)) + (text A pattern match on a GADT requires the + + text GADTs or TypeFamilies language extension) -- Trac #2905 decided that a *pattern-match* of a GADT -- should require the GADT language flag. -- Re TypeFamilies see also #7156 ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits -- 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: Performance regression on typechecking type families?
I'm certainly unaware of any reason this should be expected. I would report as a bug, and, personally, would label it High priority. I think there is plenty of room for GHC to be more efficient around type families. Thanks for putting together a test! Richard On Nov 29, 2014, at 5:17 AM, Dr. ERDI Gergo ge...@erdi.hu wrote: Hi, Prompted by this question: http://stackoverflow.com/questions/26538595/more-efficient-type-level-computations-using-type-families I wrote some code today using closed type families and datakinds. Also, as a baseline, I typechecked the code using open type families from the original question. The two files are here: https://gist.github.com/gergoerdi/727f028e4c1ed158ac9a https://gist.github.com/gergoerdi/f96d1a9a58f5e3dccc18 On GHC 7.8.3, typechecking took about 45 seconds for each. However, on a 'perf' build of GHC 7.9 d8c437b3, with ghc-stage2, the first one took 1m3s and the second one 1m12s. A 40% and 60% increase in typechecking time, respectively! Is this some known regression, something surprising, or is 'perf' simply not the right build flavour for this kind of comparison? Bye, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ 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
Cross-compiling GHC for ARM (RPi)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm having some trouble cross-compiling GHC (or just making a cross-compiler, which is what I am trying to do for now). I got my toolchain through crosstool-ng. I just took the arm-unknown-linux-gnueabi sample and disabled the render the toolchain read-only option. Unfortunately nt-ng does not come with ncurses, so I also compiled and installed that. I set the prefix to ~/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot, where ~/x-tools/arm-unknown-linux-gnueabi is where my toolchain is located. I copied the mk/build.mk.sample file to mk/build.mk and uncommented the quick-cross option. I left everything else as-is. After configuring I executed make, which runs for quite a while but eventually it complains about not being able to find the curses headers. What do I do to fix this? I wouldn't mind using a different toolchain if I can get it to work, so I am open for anything. Configure summary of ncurses and last lines of output of make: http://hastebin.com/uwuwenucux.txt I hope you can help me resolve this, I've been trying to do this for a long time now :/ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUe6uhAAoJEGBf7SEXmH6sIMkH/3eK500hnjjN3+hv/7P0YmY2 QVcDWJxRMgnFCyFA9oxAeJYqKeIps2H3555NSLdB19DK7QCG1x4TJpUBGCz09PfX mH8ZN2qIirHIYUHOZa5JdE8cqvWd3hI1syr22PsxqyI4tkDuIfKsAp8IbJOd/vSX 9oqKjHe0OYHKIoUUlHST1AI2lElMby69nxBMprhU8yugIyEFSmQg+nuxG2Hq5GA4 SgOExWeuJHrxIAW0WZ8vipw7PG3IfJTzDSCMzIAPfri8TVhy2UNNVpjg4aaq//X0 TXXweFS1O/EpDSuRkU/2b5nGlxbaNObLI5eAJ0Lot7Pl5Oa1afK5l5ZWYipx+Fk= =ol51 -END 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 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
