December 2013 - ghc-devs

Common Context transformation for join points
by Joachim Breitner 31 Dec '13

31 Dec '13

Hi all, I just came up with this, and unless I write it down I doubt I’ll be able to fall asleep. The problem I’m trying to solve is the bad interaction of the CPR worker wrapper transformation and join points. Consider, as a running example: f x = let $j n = Just (Int# (n +# 1)) in case x of A -> $j 1 B -> $j 2 C -> Just undefined The join point $j has the important property that in the final code, it can be jumped to, because its result is also the result of f, so no function closure has to be allocated for it. It seems that this is crucial for performance. But now lets do CPR, and just for demonstration, do nested CPR (the effect can also occur with non-nested CPR). Doing w/w we get $wf x = case ( let $w$j n = n +# 1 $j n = Just (Int# ($w$j n)) in case x of A -> $j 1 B -> $j 2 C -> Just undefined ) of Just n -> n f x = Just ($wf x) now we simplify, i.e. move the worker transformation inside, and inline $j’s wrapper. (I hope I am doing this right; but this is what I expect to happen): $wf x = let $w$j n = n+1 in case x of A -> Int# ($w$j 1) B -> Int# ($w$j 2) C -> undefined f x = Just ($wf x) So f’s worker transformation has nicely canceled with the invocations of Just, but it still leaves a "Int#" invocation around $w$j, so we lose the no-let-escape property of it and get worse code in the backend. This will always happen if the join point function gets a richer CPR property than the function that it belongs to, and is the reason for some hacks in the CPR code (i.e. no CPR for locally stuff that returns a sum type... not nice.) I think I have a solution for this. One observation is that these $j-functions are not really functions of their own. For this transformation (and possibly for others), one should try to treat them so that they behave as if they were inlined. So here is the idea: We do not do any w/w for $j at first, on the premise that it is not a proper function of its own. We do w/w for f as before, and simplify as before, ending up with $wf x = let $j n = Just (Int# (n +# 1)) in case x of A -> case $j 1 of Just n -> n B -> case $j 2 of Just n -> n C -> undefined f x = Just ($wf x) so we temporarily broke the property. Now a new simplifier step kicks in: For a let that looks like it was or should be a join point (hand waving here – one could possibly do it for all non-recursive lets, maybe there is even more to gain), we find out for all uses of $j applied to its arity number of arguments, what is the largest common context? where a context is * ·, the trivial context, * case c of ..., where c is a context, and ... does not contain a call to $j, * f c, where c is a context and f does not contain a call to $j, or * c x, where c is a context and f does not contain a call to $j. In particular we do not include code here where $j is part of an alternative of a case. (Casts should ok fine as well, ignoring them for now.) In our example, the context would be "case · of Just n -> n". Once we have found that, I believe it will be always safe and beneficial to replace the body e of $j by c[e], and in the body of the let replace every c[$j args..] by $j args. In our example, we would obtain $wf x = let §j n = case Just (Int# (n +# 1)) of Just n -> n in case x of A -> $j 1 B -> $j 2 C -> undefined f x = Just ($wf x) which then in further steps simplifies to the in all respects ideal code $wf x = let §j n = Int# (n +# 1)) in case x of A -> $j 1 B -> $j 2 C -> undefined f x = Just ($wf x) Implementationwise I figured that this will need two traversals (down and up each) of the let body: Starting from a let binding that looks promising (e.g. one-shot non-recursive lambda), walk down the body until invocations of the right arity are found. Then walk back returning a growing contest, and at case-expressions lub these contexts by taking their common prefix (or suffix, depends on how they are represented :-)). Then decide whether the transformation is useful (i.e. the context is non-trivial), and if so, walk back down to find the $j invocations again, and then walk back, removing the final context while doing so. I believe this would make some let-no-escape-related reluctanceness in the CPR-analysis obsolete, which would be great. And it might be a worthwhile transformation on its own (if it actually does occur), as it reduces code size without any downside (as far as I can see). Now it is likely that I thought of something existing here, or of something that has been tried and found not useful or feasible. If so, please let me know. Good night, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 3

More GND + role inference woes
by Edward Kmett 31 Dec '13

31 Dec '13

Ben Gamari was trying to update my linear package to work with GHC HEAD. Along the way he noted an example of the new GND+role inference machinery failing rather spectacularly. http://hackage.haskell.org/package/linear-1.3/docs/src/Linear-Affine.html#P… Note the number of classes that the current proposal would force us to hand implement. =( -Edward

5 20

whats our timeline for 7.8 release?
by Carter Schonwald 30 Dec '13

30 Dec '13

hey all, many many folks are wondering about when 7.8 is going to hit RC officially. What are the bugs / blockers / etc that are left to deal with? We should at least aim to communicate whats going on instead of leaving folks wondering. -Carter

3 3

Renaming Void#
by Krzysztof Gogolewski 30 Dec '13

30 Dec '13

Hello, Small bikeshedding: I propose to rename recently added Void# (in GHC.Prim) to Unit#, and void# to unit#. As far as I understand, this type is the unboxed equivalent of () (i.e. single-element type) rather than Void (i.e. empty type). The name Void# might be reserved for a type which has completely no inhabitants. Any comments? KG

5 5

Preparing for a review of pattern synonyms
by Dr. ERDI Gergo 29 Dec '13

29 Dec '13

Hi, I believe I've finished implementing version 1 of pattern synonyms (i.e. everything described in #5144, minus the things in #8581, #8582, #8583 and #8584). I've discussed the way forward with SPJ and he suggested because of the cross-cutting nature of the patch, I should wait a reasonably long time (~1 month) after 7.8 is branched off for things to settle, and then formally submit it for review. So my question is, is there anything I can do in the meantime, in preparation for the review? The code is available at https://github.com/gergoerdi/ghc. I've also added some tests to the testsuite (https://github.com/gergoerdi/ghc-testsuite) and updated the wiki pages at https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms and https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation. Thanks, Gergo

5 15

RC timeline for 7.8 REDUX
by Carter Schonwald 27 Dec '13

27 Dec '13

Hey Everyone, what is the set of tasks left before we can do a 7.8 RC? Is it there are some serious bugs that have been left unaddressed? Is there anything preventing us from doing an RC sometime in the next two weeks? I understand certain type system related problems have been getting a bit of polish over the past month or so, but if thats the blocker I'd like to know so that when people ask I can point to a concrete reason. I can only speak for myself, but theres been a pretty painful communication gap about whats left before we hit RC, and whenever someone asks me "when is 7.8 coming out, and how can i help make it happen on time?", I can only reply with "no one knows" and "do stuff". that said, happy holidays and preemptive happy new years to everyone! -Carter

2 2

GeneralizedNewtypeDeriving regression in HEAD?
by Nathan Howell 27 Dec '13

27 Dec '13

I can't file a trac ticket at the meny but wanted to see if this is a bug... This is an excerpt from llvm-general that compiles on 7.6.3 but doesn't without ImpredicativeTypes enabled on HEAD: https://gist.github.com/NathanHowell/8138977 thanks, -n

2 1

My first patch
by Krzysztof Langner 25 Dec '13

25 Dec '13

Hello, Since I'm new here I will first introduce myself. My name is Krzysztof and I have more then 20 years experience with object oriented languages. Recently I learned about functional programming. And I really like it. Because my current project uses OO languages (no FP) I decided to try to engage with GHC development to learn Haskell. So here is my first patch. It is related to the ticket: https://ghc.haskell.org/trac/ghc/ticket/5412 I just changed error message so it should be easier (I hope) to understand what has happened. No functionality was changed. The patch is attached to the ticket. Should I submit it to someone to review? -- Thanks Krzysztof Langner

2 2

Help needed: adding pattern synonym support to Haddock
by Dr. ERDI Gergo 20 Dec '13

20 Dec '13

Hi, I've started looking at adding pattern synonym support to Haddock (as part of #5144), but I've realized that pattern synonyms are different enough from other, existing declarations that are processed by Haddock that I'd like to discuss it first. Who would be 'the Haddock guy' to talk to? Thanks, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' Duct tape is like the force; it has a light side and a dark side, and it holds the universe together.

2 1

Building GHC in a small amount of memory, in parts.
by Aaron Friel 19 Dec '13

19 Dec '13

I am trying to build GHC-HEAD and produce a reliable Dockerfile (see: docker.io) to allow others to use GHC-HEAD and also to make my own build process more reliable. I would like advice/assistance on two things to help this. For reference, I am using the stackbrew/ubuntu:13.10 image as my starting point, and bootstrapping GHC to HEAD using the current GHC (7.6.x) in Ubuntu's repositories. First issue: I am having issues with constraining the resource consumption during the build and have resorted to a few hacks such as replacing ld with gold (or rather, a script that filters out --hash-size arguments) and a custom build.mk file that uses -fasm for stage1. I would also like the final (stage 2?) result to be compiled with llvm, perhaps even without requiring gcc installed at all. How can I continue to push down the resource requirements of a build, and end up with a GHC that represents the bleeding edge? (That is what I want to be testing against, finding bugs for, etc.) Here is my build.mk: ################## BUILD.MK # Default to a very fast build for compilation and stage1: SRC_HC_OPTS = -H64m -O0 GhcStage1HcOpts = -O -fasm # But then use perf-llvm settings for remaining settings: GhcStage2HcOpts = -O2 -fllvm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 -fllvm -XGenerics GhcLibWays += p DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO # Disable building all docs HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO ################## BUILD.MK Second issue: These seem to bring memory usage down, but the monolithic ".\make" command is difficult to debug and very time consuming. When building a container image from a Dockerfile, the commands used are cached so that subsequent attempted builds use the intermediate results. So, even though my Dockerfile starts out with "apt-get update; apt-get upgrade -y", I don't have to do that every time I retry my build. Currently my Dockerfile pulls all the requisite packages from Ubuntu's repos, downloads and builds the latest cabal-install and builds alex, happy, hscolour and haddock, gets the ghc repo from GitHub, does "perl boot" ".\configure" and then I hit a wall with the monstrous amount of work that ".\make" does. I have tried splitting it up by doing ".\make stage=1", ".\make 1", and various combinations, but I hit dependency issues. Is there a way to break up the build into multiple commands?

1 0