March 2015 - ghc-devs

RE: vectorisation code?
by Simon Peyton Jones 12 Sep '16

12 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35

arc land changes author
by Joachim Breitner 19 Dec '15

19 Dec '15

Hi, I was just about to apply a DR by David. First I ran $ arc patch D390 which put me on a feature branch. Then I reworded the commit with $ git commit --amend and then I tried to land it with $ arc land Luckily I also passed --hold... It even asked me if I want to land the commit although I am not the author: This branch has revision 'D390: Reorder GHC.List; fix performance regressions' but you are not the author. Land this revision by dfeuer? [y/N] y But it still put me in the author field: $ git show HEAD commit a387c359b99667ce55016de3816b5d9873a155db Author: Joachim Breitner <mail(a)joachim-breitner.de> Date: Wed Oct 29 08:17:05 2014 +0100 Reorder GHC.List; fix performance regressions Summary: Rearrange some oddly placed code. (and undid my commit message changes....) Did I do something wrong? Anyways, it said something along the lines of Cleaning up feature branch... (Use `git checkout -b 'arcpatch-D390' 'a3ceb0e7f44d53f728fb8bd0dfb4c97297818029'` if you want it back.) so with $ git commit --amend -C a3ceb0e7f44d53f728fb8bd0dfb4c97297818029 I was able to get the edited commit message with the right author back. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

2 2

Cabal and simultaneous installations of the same package
by Simon Peyton Jones 29 Aug '15

29 Aug '15

Dear Cabal developers You'll probably have seen the thread about the Haskell Platform. Among other things, this point arose: | Another thing we should fix is the (now false) impression that HP gets in | the way of installing other packages and versions due to cabal hell. People mean different things by "cabal hell", but the inability to simultaneously install multiple versions of the same package, compiled against different dependencies is certainly one of them, and I think it is the one that Yitzchak is referring to here. But some time now GHC has allowed multiple versions of the same package (compiled against different dependencies) to be installed simultaneously. So all we need to do is to fix Cabal to allow it too, and thereby kill of a huge class of cabal-hell problems at one blow. But time has passed and it hasn't happened. Is this because I'm misunderstanding? Or because it is harder than I think? Or because there are much bigger problems? Or because there is insufficient effort available? Or what? Unless I'm way off beam, this "multiple installations of the same package" thing has been a huge pain forever, and the solution is within our grasp. What's stopping us grasping it? Simon

11 21

Backporting srcLoc to the GHC 7.10 branch
by Michael Snoyman 15 Jul '15

15 Jul '15

It looks like the srcLoc change[1] is something that some of our (FP Complete's) customers would be quite interested in getting access to sooner rather than later. Would there be any possibility of getting that patch merged into the 7.10 branch of GHC? I'm not sure if I'd try my luck at actually including it in 7.10.1, but would it be on the table for 7.10.2? We do of course have the option of backporting it ourselves and including it in a custom GHC we provide customers, but we generally try to stay as close to upstream as possible. [1] https://ghc.haskell.org/trac/ghc/ticket/9049

9 20

Right way to turn off dynamic linking in build.mk
by Johan Tibell 07 Jul '15

07 Jul '15

Some times when I play around with GHC I'd like to turn off dynamic linking to make GHC compile faster. I'm not sure what the right way to do this in build.mk. It's made confusing by the conditional statements in that file: GhcLibWays = $(if $(filter $(DYNAMIC_GHC_PROGRAMS),YES),v dyn,v) This line make me worry that if I don't put DYNAMIC_GHC_PROGRAMS = NO in the right place in build.mk it wont "take". There's also this one: ifeq "$(PlatformSupportsSharedLibs)" "YES" GhcLibWays += dyn endif Seeing this makes me wonder if DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO is enough or if the build system still sniffs out the fact that my platform supports dynamic linking. Could someone please give an authoritative answer to how to turn off dynamic linking? -- Johan

4 5

MSYS2 package for GHC 7.10.1
by David Macek 04 Jun '15

04 Jun '15

Hi everyone. After finally putting some uninterruped effort into it, I managed to create (hopefully) working prototypes of two GHC-related packages for MSYS2, namely ghc[1] and cabal-install[2]. I've prepared recipes (PKGBUILDs) for building from source, but 64-bit binaries[5][6] are also provided for those who'd like to test my build without building it themselves. With this post, I'd like to start some work towards the following goals (I hope we can get some Windows discussion going again): - verify that the build is reproducible (see below for instructions) - make tests pass - fix known issues (see below for list) - discover and fix unknown issues - review and upstream as many patches as possible - make it easier for people on Windows to start hacking on GHC I'll be glad to read any responses, notes, results, hints, comments and/or criticisms. Please note that I'm writing this after being submerged in the matter for some time, so don't be surprised to see any glaring omissions or obvious mistakes. Known issues ============ Configure has a problem with docbook - This mean Haddock is not built. It's probably some silliness on the part of MSYS2's docbook. Integer-gmp object file has a reference to __mingw_vsnprintf - Compiling seems to work fine, presumably because the final link command includes -lmingwex, but `runhaskell Setup.lhs` in the text package source tree gave me an undefined reference error, causing inability to load integer-gmp module. I don't know where to start fixing this, as I have not yet reached the depth of understanding of GHC source needed for that. Wildly untested - I didn't try building with LLVM and the testsuite is currently failing to start, giving some weird errors. Trying cross compiling or compiling a cross compiler didn't even cross my mind (har har). Patches ======= A lot of the patches deal with the directory structure -- I tried to mirror the common FHS layout as closely as possible while still retaining the advantages of relocatability. I also removed the bundled toolchain and perl, in favor of packages included with MSYS2. I assume these changes are somewhat controversial for upstreaming, but it'd be nice to see the official bindists to adopt this layout. There are several patches that I think are more of straight-forward fixes rather than design changes, namely numbers 0007, 0010, 0014 and 0015. Build instructions ================== General build instructions[3] are available at our wiki. For convenience, I've compiled a sequence of commands that should get you the ghc and cabal-install packages, given that you start with an up-to-date installation of MSYS2 and a working GHC in PATH. Refer to our guide[4] for correct way of getting/upgrading your MSYS2. ## start MSYS2 shell pacman --needed -S base-devel mingw-w64-x86_64-toolchain mingw-w64-i686-toolchain git clone https://github.com/elieux/mingw-packages cd mingw-packages git checkout ghc pushd mingw-w64-ghc makepkg-mingw -sLf pacman -U mingw-w64-*-ghc-*-any.pkg.tar.xz ## remove old GHC from PATH popd pushd mingw-w64-cabal-install makepkg-mingw -sLf pacman -U mingw-w64-*-cabal-install-*-any.pkg.tar.xz popd If you prefer to build only for one architecture, export a variable named MINGW_INSTALLS with a value of "mingw32" or "mingw64" before building. == [1] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-ghc [2] https://github.com/elieux/mingw-packages/tree/ghc/mingw-w64-cabal-install [3] http://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/ [4] http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ [5] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-cabal-install… [6] https://dl.dropboxusercontent.com/u/59899181/mingw-w64-x86_64-ghc-7.10.1-1-… -- David Macek

3 5

stack traces when debugging GHC
by Richard Eisenberg 14 Apr '15

14 Apr '15

Hi devs, I've just made a miraculous discovery and I want to share! It has happened many times that I create some bizarre error in GHC and have no clue where it comes from. In the past, I've ended up using pprTrace to label all calls of the failing function, sometimes recursively, until I get an idea of what's going on. This is terribly painful. And then, I noticed that the function Debug.Trace.traceStack (just in the `base` package, not part of GHC) will print out a stack trace, when profiling is enabled. So, I tried building a profiled build of GHC, with -DDEBUG and -fprof-auto (just by editing the "prof" section of build.mk). And then, voila, ASSERTs now print stack traces! And, with a small change in Outputable, I can get pprTrace to print stack traces, too! Hooray! I'd love to put this on the wiki. Any clue where this might be found? Richard

5 5

DynFlags.hs
by Kazu Yamamoto 06 Apr '15

06 Apr '15

Hi, I cannot build GHC 7.10.1 on CentOS 6.5 whose memory is just 1G. This is because compiler/main/DynFlags.hs is huge. It would be nice if this file could be split. --Kazu

3 2

GHC 7.10.1 html docs all flat?
by Randy Polen 02 Apr '15

02 Apr '15

The HP build expects that the html docs for the ghc-bundled packages will be in heirarchical directories, based on the package name (e.g., GHC.Magic docs in libraries/ghc-prim-0.3.1.0/GHC-Magic.html) which is how it has been for many ghc releases. In 7.10.1, I thought it was an error but it seems the haskell.org docs reflect this new, flat way (e.g,. GHC.Magic docs in libraries/GHC-Magic.html). Just want to make sure this is what is expected, and then change the HP build code accordingly. Follow up question: should the HP-bundled docs do the same thing? Is the flat model the way to go for all the docs? Won't this cause collisions for updated packages? Randy

3 2

Typeable
by Simon Peyton Jones 02 Apr '15

02 Apr '15

Iavor, Richard, and others We always thought it was the Right Thing to generate the runtime representation for a TyCon (used in Typeable type representations) at the definition site of the type, not "on the fly". I thought I'd do this. But it was a LOT harder than I expected. I have spent a ridiculous amount of time on it over the last three weeks. Sigh. However (a) it's done, (b) I did a lot of other tidying up (as usual). So I'm keen to use it. Would you like to take a look? It's on branch wip/T9858-typeable-spj. Relevant log messages below. Unsurprisingly, some perf/compiler tests get a bit slower (see below). More surprisingly, there are two perf/should_run tests that get worse perf/should_run T5205 [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat not good enough] (normal) This is much more surprising: neither seems to have anything much to do with Typeable. But I can't investigate before I go on holiday. Would anyone else like to? It's all up to date wrt HEAD. Simon commit fcd18c42b6ae2e73a9f4c67dbe6d994b0f8468c8 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Mar 26 11:06:12 2015 +0000 Remove a redndant 'return' commit a6200759fd2f3f0e901cb2092e148bf31abb08b4 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Mar 23 14:53:53 2015 +0000 Error message wibbles These are associated with - new instance reporting - typeable changes in -ddump-simpl output - -ddump-types being a bit less verbose - some renaming of type variables in debugger output (no idea why this happens) commit fe510d911b6cf61d6884b8b42d8771d4aea3229f Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Mar 23 14:50:23 2015 +0000 Generate Typeble info at definition sites This patch implements the idea floated in #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: - we need to have enough data types around to *define* a TyCon - many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp T1969 T1969: GHC allocates 30% more T5642: GHC allocates 14% more T9872d: GHC allocates 5% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, - a type *family* (whether type or data) is repesented by a FamilyTyCon - a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. * I added PatSynId, DefMethId, and ReflectionId to the IdInfo.IdDetails type. They are used for debugging only, namely to suppress excessive output in -ddump-types. * Tidy up the generation of PrelInfo.knownKeyNames * Move newImplicitBinder from IfaceEnv to BuildTyCl * PrelNames.conName renamed to dcQual for consistency with varQual, tcQual * Move mkDefaultMethodIds, mkRecSelBinds from TcTyClsDecls to TcTyDecls commit 021e6f583a1159b0a3581ab1713d560cadc2bdf7 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Mar 23 14:32:31 2015 +0000 tcRnDeclsi can use tcRnSrcDecls I'm not sure why tcRnDeclsi didn't call tcRnSrcDecls before, but now it does. About 20 lines of code vanish. Hooray. commit 6473d110ab1aa22a5933e405b59e3f597562ce02 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Mar 20 12:38:42 2015 +0000 Implement lookupGlobal in TcEnv, and use it This localises the (revolting) initTcForLookup function, exposing instead the more civilised interface for lookupGlobal commit 7078a11f50e3af9139dd5ceef032e89047677833 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Mar 20 12:36:22 2015 +0000 Comments and white space commit 48512df5751a07fd503f0ba523e5504d09ee258d Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Mar 20 12:27:59 2015 +0000 Improve the error messages for class instance errors See Note [Displaying potential instances]. simonpj@cam-05-unx:~/code/HEAD-5$

2 3