- ghc-devs - Haskell.org

GHC Weekly News - 10/24/2014
by Austin Seipp 30 Oct '14

30 Oct '14

Note: this post is available (with full hyperlinks) at https://ghc.haskell.org/trac/ghc/blog/weekly20141024 --------- Hi *, Welcome to the weekly GHC news. This one will be short this week, as the preceding one occurred only on Monday - but we'll be going with Fridays from now on, so next week we'll hopefully see a longer list. - GHC 7.8.4 tickets have been in waiting, and the RC will be soon after Austin finishes some final merges and tests on his branch. **We have not committed a time for the release after the RC**, yet we would like people to **please seriously test** and immediately report any major showstoppers - or alert us of ones we missed. - For the GHC 7.10 release, one of the major features we planned to try and merge was DWARF debugging information. This is actually a small component of larger ongoing work, including adding stack traces to Haskell executables. While, unfortunately, not all the work can be merged, we talked with Peter, and made a plan: our hope is to get Phab:D169 merged, which lays all the groundwork, followed by DWARF debugging information in the code generators. This will allow tools like `gdb` or other extensible debuggers to analyze C-- IR accurately for compiled executables. Peter has written up a wiki page, available at SourceNotes, describing the design. We hope to land all the core infrastructure in Phab:D169 soon, followed by DWARF information for the Native Code Generator, all for 7.10.1 - This past week, a discussion sort of organically started on the `#ghc` IRC channel about the future of the LLVM backend. GHC's backend is buggy, has no control over LLVM versions, and breaks frequently with new versions. This all significantly impacts users, and relegates the backend to a second class citizen. After some discussion, Austin wrote up a proposal for a improved backend, and wrangled several other people to help. The current plan is to try an execute this by GHC 7.12, with the goal of making the LLVM backend Tier 1 for major supported platforms. - You may notice https://ghc.haskell.org is now responds slightly faster in some cases - we've activated a caching layer (CloudFlare) on the site, so hopefully things should be a little more smooth. Closed tickets this week: #9684, #9692, #9038, #9679, #9537, #1473. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 3

RE: [commit: ghc] wip/T9732: Generate two versions of pattern synonym matcher: * one where the continuation is lifted, * one where the continuation is unlifted. (423e9b2)
by Simon Peyton Jones 30 Oct '14

30 Oct '14

No no! Let's not do that. It's grotesque to generate identical code twice. We must find a better way. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 30 October 2014 15:40 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/T9732: Generate two versions of pattern | synonym matcher: * one where the continuation is lifted, * one where | the continuation is unlifted. (423e9b2) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/T9732 | Link : | http://ghc.haskell.org/trac/ghc/changeset/423e9b28930fb9e6dfcd4a20dd60 | 4ec488a2bb1d/ghc | | >--------------------------------------------------------------- | | commit 423e9b28930fb9e6dfcd4a20dd604ec488a2bb1d | Author: Dr. ERDI Gergo <gergo(a)erdi.hu> | Date: Thu Oct 30 23:07:50 2014 +0800 | | Generate two versions of pattern synonym matcher: | * one where the continuation is lifted, | * one where the continuation is unlifted. | | | >--------------------------------------------------------------- | | 423e9b28930fb9e6dfcd4a20dd604ec488a2bb1d | compiler/basicTypes/OccName.lhs | 5 +++-- | compiler/basicTypes/PatSyn.lhs | 21 ++++++++++++--------- | compiler/deSugar/DsUtils.lhs | 2 +- | compiler/iface/BuildTyCl.lhs | 7 ++++--- | compiler/iface/IfaceSyn.lhs | 8 ++++++-- | compiler/iface/MkIface.lhs | 4 +++- | compiler/iface/TcIface.lhs | 4 +++- | compiler/typecheck/TcBinds.lhs | 3 ++- | compiler/typecheck/TcPatSyn.lhs | 28 +++++++++++++++++----------- | 9 files changed, 51 insertions(+), 31 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 423e9b28930fb9e6dfcd4a20dd604ec488a2bb1d | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

Re: cabal sdist trouble with GHC from head
by Sven Panne 30 Oct '14

30 Oct '14

2014-10-29 23:55 GMT+01:00 Herbert Valerio Riedel <hvriedel(a)gmail.com>: > Fyi, there's a `cabal-install-head` package now[1] (may take a few > minutes till its properly published in the PPA though); please test it > and lemme know if it works as expected... > > [1]: https://launchpad.net/~hvr/+archive/ubuntu/ghc/+sourcepub/4539223/+listing-… Thanks for uploading this. Nevertheless, GHC from head and cabal from head still don't like each other: https://travis-ci.org/haskell-opengl/StateVar/jobs/39470537#L103 I get "cabal: Prelude.chr: bad argument: 3031027"... o_O

1 0

Windows build broken in Linker.c
by Simon Peyton Jones 29 Oct '14

29 Oct '14

Simon Aargh! I think the Windows build is broken again. I think this is your commit 5300099ed Admittedly this is on a branch I'm working on, but it's up to date with HEAD. And I have no touched Linker.c! Any ideas? Simon rts\Linker.c: In function 'allocateImageAndTrampolines': rts\Linker.c:3708:19: error: 'arch_name' undeclared (first use in this function) rts\Linker.c:3708:19: note: each undeclared identifier is reported only once for each function it appears in rts/ghc.mk:236: recipe for target 'rts/dist/build/Linker.o' failed make[1]: *** [rts/dist/build/Linker.o] Error 1 make[1]: *** Waiting for unfinished jobs....

4 8

File Header Pragmas in Lexer
by Alan & Kim Zimmerman 29 Oct '14

29 Oct '14

As part of my ongoing efforts to round-trip source code, I have bumped into an issue around file header pragmas, e.g. {-# LANGUAGE PatternSynonyms #-} {-# Language DeriveFoldable #-} {-# options_ghc -w #-} In normal mode, when not called from headerInfo, the file header pragmas are lexed enough to generate a warning about an invalid pragma if enabled, and then lexed to completion and returned as an `ITblockComment` if `Opt_KeepRawTokenStream` is enabled. The relevant Alex rule is <0> { -- In the "0" mode we ignore these pragmas "{-#" $whitechar* $pragmachar+ / { known_pragma fileHeaderPrags } { nested_comment lexToken } } The problem is that the tokens returned are ITblockComment " PatternSynonyms #" ITblockComment " DeriveFoldable #" ITblockComment " -w #" It is not possible to reproduce the original comment from these. It looks like nested comment ignores what has been lexed so far nested_comment :: P (RealLocated Token) -> Action nested_comment cont span _str _len = do ... So my question is, is there any way to make the returned comment include the prefix part? Perhaps be a specific variation of nested_comment that uses str and len. Alan

1 1

emailing to Trac?
by Richard Eisenberg 29 Oct '14

29 Oct '14

Hi devs, There's a feature I've wanted for some time, and I don't see a good reason not to ask: Is it possible to email comments into Trac? My commute involves a ~40 minute train ride, which I generally can use productively despite no connection. One of the biggest annoyances, though, is that I can't respond to Trac comments while on the train. It would be great if there were an email address to write to that would post a comment. Of course, it's easy enough for me to write and locally cache a response, but then I have to remember to flush the cache and it's all a bit annoying. Does Trac have this feature? Is it perhaps already enabled but not advertised? Thanks! Richard

2 1

Is USE_REPORT_PRELUDE still useful?
by David Feuer 29 Oct '14

29 Oct '14

A lot of code in GHC.List and perhaps elsewhere compiles differently depending on whether USE_REPORT_PRELUDE is defined. Not all code differing from the Prelude implementation. Furthermore, I don't know to what extent, if any, such code actually works these days. Some of it certainly was not usable for *years* because GHC.List did not import GHC.Num. Should we 1. Convert all those code blocks to comments? 2. Go through everything, check it to make sure it's written as in the Prelude or has an alternative block, and then actually set up all the infrastructure so that works? 3. Leave it alone? My general inclination is to go to 1. I don't *really* like option 3 for four reasons: a. It leaves untouched code to rot b. It forces us to run CPP on files that otherwise have no need for it. c. It interrupts the flow of the code with stuff that *looks* like real code (and is highlighted as such) but is actually inactive. d. It's not hard to accidentally move code into or out of the #ifdef blocks.

4 4

Call Arity, oneShot or both
by Joachim Breitner 28 Oct '14

28 Oct '14

Hi, some months ago I tried to make foldl a good consumer in the common case. The starting point is always to write foldl k a xs = foldr (\v f a -> f (v `k` a)) id xs a and then somehow make GHC produce good code with this. I came up with two solutions: A more sophisticated compiler analysis (Call Arity), or an explicit annotation in the form of foldlB k a xs = foldr (\v f -> oneShot (\a -> f (v `k` a))) id xs a where oneShot :: (a -> b) -> (a -> b) is a built-in function, semantically the identity, but telling the compiler that it can assume that the (\a -> ...) is called at most once. Back then, we decided to use Call Arity, on the grounds that it might improve other code as well, despite not having a lot of evindence that this may happen. Then recently David Feuer built on my work by making more functions fuse, including functions like scanl that are not built on foldl, but benefit from the same analysis. This supports the usefulness of Call Arity. But he also found cases where Call Arity is not powerful enough and GHC would produce bad code. So I wanted to properly compare Call Arity with the oneShot approach. Based on todays master (0855b249), I disabled Call Arity and changed the definitions of foldl, foldl', scanl and scanl' to use oneShot, and ran nofib. The result are mixed. With the current code, the oneShot machinery does not always work as expected: Program Size Allocs Runtime Elapsed TotalMem Min -0.1% -1.5% -2.8% -2.8% -5.8% Max +0.4% +4.7% +5.8% +5.6% +5.4% Geometric Mean -0.0% +0.1% +0.3% +0.3% +0.1% The biggest loser is calendar, which uses scanl. I am not fully sure what went wrong here: Either the one-shot annotation on the lambda’s variable got lost somewhere in the pipeline, or despite it being there, the normal arity analysis did not use it. But there is also a winner, fft2, with -1.5% allocations. Here Call Arity was not good enough, but oneShot did the jobs. There is also the option of combining both. Then we do not get the regression, but still the improvement for fft2: Min -0.1% -1.5% -3.9% -3.8% -5.8% Max +0.2% +0.1% +6.4% +6.3% +13.1% Geometric Mean -0.0% -0.0% +0.0% +0.0% +0.1% The oneShot code is on the branch wip/oneShot. The changes are clearly not ready to be merged. In particular, there is the question of how to best keep the oneShot annotation in the unfoldings: The isOneShotLambda flag is currently not stored in the interface. I work around this by making sure that the oneShot function is never inlined in unfoldings, but maybe it would be better to serialize the isOneShotLambda flag in interfaces, which might have other good effects? If we want as much performance as possible, we should simply include both approaches. But there might be other things to consider... so not sure what the best thing to do is. 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

3 8

Re: Call Arity, oneShot or both
by David Feuer 28 Oct '14

28 Oct '14

Simon Peyton Jones wrote: > > But since it is plausible that there are cases out there where it might > help, even if just a little, we could go forward ?unless the > implementation becomes ugly. > Based on our experience with Call Arity, it's much more likely that it will help a lot in a few cases than that it will help a little in a lot of cases. David

1 0

Re: [commit: ghc] master: Implementation of hsig (module signatures), per #9252 (aa47995)
by Joachim Breitner 28 Oct '14

28 Oct '14

Hi Edwardd, Am Freitag, den 24.10.2014, 23:47 +0000 schrieb git(a)git.haskell.org: > >--------------------------------------------------------------- > > commit aa4799534225e3fc6bbde0d5e5eeab8868cc3111 > Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> > Date: Thu Aug 7 18:32:12 2014 +0100 > > Implementation of hsig (module signatures), per #9252 this breaks a few test cases: Actual stderr output differs from expected: --- ./ghci/scripts/T5979.stderr 2014-10-24 23:49:33.395524791 +0000 +++ ./ghci/scripts/T5979.run.stderr 2014-10-25 00:24:08.934279006 +0000 @@ -2,6 +2,6 @@ <no location info>: Could not find module â€˜Control.Monad.Trans.Stateâ€™ Perhaps you meant - Control.Monad.Trans.State (from transformers-0.4.1.0@trans_GjLVjHaAO8fEGf8lChbngr) - Control.Monad.Trans.Class (from transformers-0.4.1.0@trans_GjLVjHaAO8fEGf8lChbngr) - Control.Monad.Trans.Cont (from transformers-0.4.1.0@trans_GjLVjHaAO8fEGf8lChbngr) + Control.Monad.Trans.State (from transformers-0.4.1.0@trans_5jw4w9yTgmZ89ByuixDAKP) + Control.Monad.Trans.Class (from transformers-0.4.1.0@trans_5jw4w9yTgmZ89ByuixDAKP) + Control.Monad.Trans.Cont (from transformers-0.4.1.0@trans_5jw4w9yTgmZ89ByuixDAKP) *** unexpected failure for T5979(ghci) Actual stdout output differs from expected: --- ./safeHaskell/check/pkg01/safePkg01.stdout 2014-10-24 23:49:33.705509654 +0000 +++ ./safeHaskell/check/pkg01/safePkg01.run.stdout 2014-10-25 00:19:17.451490530 +0000 @@ -29,17 +29,17 @@ require own pkg trusted: True M_SafePkg6 -package dependencies: array-0.5.0.1@array_5q713e1nmXtAgNRa542ahu +package dependencies: array-0.5.0.1@array_GX4NwjS8xZkC2ZPtjgwhnz trusted: trustworthy require own pkg trusted: False M_SafePkg7 -package dependencies: array-0.5.0.1@array_5q713e1nmXtAgNRa542ahu +package dependencies: array-0.5.0.1@array_GX4NwjS8xZkC2ZPtjgwhnz trusted: safe require own pkg trusted: False M_SafePkg8 -package dependencies: array-0.5.0.1@array_5q713e1nmXtAgNRa542ahu +package dependencies: array-0.5.0.1@array_GX4NwjS8xZkC2ZPtjgwhnz trusted: trustworthy require own pkg trusted: False *** unexpected failure for safePkg01(normal) https://s3.amazonaws.com/archive.travis-ci.org/jobs/38981598/log.txt It seems you need to adjust the testsuite to remove these hashes before comparing the output. 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 1