- ghc-devs - Haskell.org

Re: Understanding core2core optimisation pipeline
by Jan Stolarek 31 Oct '14

31 Oct '14

I'm resurrecting this 3-month old thread as I have some more questions about cardinality analysis. 1. I'm still a bit confused about terminology. Demand analysis, strictness analysis, cardinality analysis - do these three terms mean exactly the same thing? If no, then what are the differences? 2. First pass of full laziness is followed by floating in. At that stage we have not yet run the demand analysis and yet the code that does the floating-in checks whether a binder is one-shot (FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam case). This suggests that cardinality analysis is done earlier (but when?) and that demand analysis is not the same thing as cardinality analysis. 3. Does demand analyser perform any transformations? Or does it only annotate Core with demand information that can be used by subsequent passes? 4. BasicTypes module defines: data OneShotInfo = NoOneShotInfo -- ^ No information | ProbOneShot -- ^ The lambda is probably applied at most once | OneShotLam -- ^ The lambda is applied at most once. Do I understand correctly that `NoOneShotInfo` really means no information, ie. a binding annotated with this might in fact be one shot? If so, then do we have means of saying that a binding is certainly not a one-shot binding? 5. What is the purpose of SetLevels.lvlMFE function? Janek > The wiki page just went live: > > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Core2CorePipeline > > It's not yet perfect but it should be a good start. > > > Roughtly, a complete run of the simplifier means "run the simplifier > > repeatedly until nothing further happens". The iterations are the > > successive iterations of this loop. Currently there's a (rather arbitrary) > > limit of four such iterations before we give up and declare victory. > > A limit or a default value for that limit? > > To Ilya: > > If you grep for the "late_dmd_anal" option variable in the compiler/simplCore/SimplCore.lhs > > module, you'll see that it triggers a phase close to the endo of getCoreToDo's tasks, which > > contains, in particular, the "CoreDoStrictness" pass. This is the "late" phase. > > The paper said that the late pass is run to detect single-entry thunks and the reason why it is > run late in the pipeline is that if it were run earlier this information could be invalidated > by the transformations. But in the source code I see that this late pass is followed by the > simplifier, which can invalidate the information. Also, the documentation for -flate-dmd-anal > says: "We found some opportunities for discovering strictness that were not visible earlier; > and optimisations like -fspec-constr can create functions with unused arguments which are > eliminated by late demand analysis". This says nothing about single-netry thunks. So, is the > single-entry thunk optimisation performed by GHC? > > Janek

3 4

RFC: Properly stated origin of code contributions
by Herbert Valerio Riedel 31 Oct '14

31 Oct '14

Hi, GHC's Git history has (mostly) a good track record of having properly attributed authorship information in the recent past; Some time ago I've even augmented the .mailmap file to fix-up some of the pre-Git meta-data which had mangled author/committer meta-data (try 'git shortlog -sn' if you're curious) However, I just noticed that http://git.haskell.org/ghc.git/commitdiff/322810e32cb18d7749e255937437ff2ef… landed recently, which did change a significant amount of code, but at the same time the author looks like a pseudonym to me (and apologies if I'm wrong). Other important projects such as Linux or Samba, just to name two examples, reject contributions w/o a clearly stated origin, and explicitly reject anonymous/pseudonym contributions (as part of their "Developer's Certificate of Origin" policy[1] which involves a bit more than merely stating the real name) I believe the GHC project should consider setting some reasonable ground-rules for contributions to be on the safe side in order to avoid potential copyright (or similiar) issues in the future, as well as giving confidence to commercial users that precautions are taken to avoid such issues. Comments? Cheers, hvr [1]: See http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documen…

11 16

Re: Understanding core2core optimisation pipeline
by David Feuer 31 Oct '14

31 Oct '14

On Thu, Oct 30, 2014 Jan Stolarek wrote: > > 2. First pass of full laziness is followed by floating in. At that stage > we have not yet run the > demand analysis and yet the code that does the floating-in checks whether > a binder is one-shot > (FloatIn.okToFloatInside called by FloatIn.fiExpr AnnLam case). This > suggests that cardinality > analysis is done earlier (but when?) and that demand analysis is not the > same thing as > cardinality analysis. > If you're looking at super-recent code, that could be Joachim Breitner's work. He's exposed the one-shot stuff at the Haskell level with the experimental magic oneShot function, intended primarily for use in the libraries to make foldl-as-foldr and related things be analyzed more reliably. The old GHC arity analysis combined with his Call Arity get almost everything right, but there are occasional corner cases where things go wrong, and when they do the results tend to be extremely bad.

5 5

RE: package hashes
by Simon Peyton Jones 31 Oct '14

31 Oct '14

No, I did not. You can try it yourself! | -----Original Message----- | From: Edward Z. Yang [mailto:ezyang@cs.stanford.edu] | Sent: 30 October 2014 19:50 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: package hashes | | Hmm. I'm not sure, but the right thing might just be to accept this | new output. But I guess I'm a bit confused, since you probably didn't | change this test-case at all, did you? | | Edward | | Excerpts from Simon Peyton Jones's message of 2014-10-30 08:26:45 - | 0700: | > Edward | > | > On branch wip/new-flatten-skolems-Oct14, I'm getting this test | failure repeatably on test safePkgO1. I'm pretty sure I have done | nothing to mess with package hashes! | > | > Any ideas? | > | > Simon | > | > =====> safePkg01(normal) 108 of 120 [0, 0, 0] | > cd ./check/pkg01 && $MAKE -s --no-print-directory safePkg01 | VANILLA=--enable-library-vanilla PROF=--disable-library-profiling | DYN=--enable-shared </dev/null >safePkg01.run.stdout | 2>safePkg01.run.stderr | > Actual stdout output differs from expected: | > --- ./check/pkg01/safePkg01.stdout 2014-10-29 15:09:16.000000000 | +0000 | > +++ ./check/pkg01/safePkg01.run.stdout 2014-10-30 | 15:25:17.799094762 +0000 | > @@ -29,17 +29,17 @@ | > require own pkg trusted: True | > M_SafePkg6 | > -package dependencies: array-0.5.0.1@array_<HASH> | > +package dependencies: array-0.5.0.1 base-4.8.0.0* | > trusted: trustworthy | > require own pkg trusted: False | > M_SafePkg7 | > -package dependencies: array-0.5.0.1@array_<HASH> | > +package dependencies: array-0.5.0.1 base-4.8.0.0* | > trusted: safe | > require own pkg trusted: False | > M_SafePkg8 | > -package dependencies: array-0.5.0.1@array_<HASH> | > +package dependencies: array-0.5.0.1 base-4.8.0.0 | > trusted: trustworthy | > require own pkg trusted: False

1 0

cabal sdist trouble with GHC from head
by Sven Panne 31 Oct '14

31 Oct '14

Does anybody have a clue what's going wrong at the sdist step here? https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707011#L104 This only happens with a GHC from head, a build with GHC 7.8.3 is fine: https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/38707010 Any help highly appreciated... Cheers, S.

4 7

URL issue
by Simon Peyton Jones 30 Oct '14

30 Oct '14

Herbert, Austin I was in a fairly old repo, but one I have been using daily, and pushing to the central repo. The pushurl was pushurl = ssh://git@ghc.haskell.org/ghc.git That worked two days ago, but silently hangs now. But when I finally realised that it should be "git.haskell.org" it works fine. So something must have changed. I'm certain I was pushing to ghc.haskell.org until a couple of days ago. Strange, and may be useful knowledge for others. Anyway, no problem now. But the "Repositories" pages says nothing about what URL to use for pushing - and it really should! That would be worth fixing. Thanks Simon

2 1

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