- ghc-devs - Haskell.org

Superclasses
by Simon Peyton Jones 20 Feb '17

20 Feb '17

Edward In comment:23 of https://ghc.haskell.org/trac/ghc/ticket/11523 I claim that there is an infinite tower of superclasses, so that GHC can legitimately spin. You have not responded for nearly a year. Do you agree? Simon

2 1

Early inline
by Simon Peyton Jones 19 Feb '17

19 Feb '17

Ben, David, Reid I have been working for months (on and off, mostly off, but very ON for the last week or two) on a very simple idea: the simplifier should inline things even in the "gentle" phase. It seems so simple. And it is: the key patch is tiny. But it stressed corners of the optimiser that were not stressed before; and digging into it showed opportunities I did not know about before. So I have ended up a with a whole series of patches, which are on wip/spj-early-inline branch 7f14d15c0e5fc2c9a81db3d0f0b01d85857b1d87 Error message wibbles accumulated from the preceding patches 0499c65d9fa45e7879e1e1264fdaa15274adcba6 Improve SetLevels for join points 3b2fc0827ff6cafa34836c2d9dc710b628c990b6 Change -ddump-tc-trace output in TcErrors, slightly 9ffdf62b0ca72c4f35579f9d6f31a9beebf23025 Improve pretty-printing of types 3f346eac06399a79adf48425018ee949cee245bf Add VarSet.anyDVarSet, allDVarSet 912e71eb3b4ec91e805ecf2236d1033e55e2933a The Early Inline Patch 7188cd13f8e54efa764d52ca016b87b3669b29f5 Small changes to expression sizing in CoreUnfold bfc6fa3f377d11bdfcdbf82b65bf2f39cb00b90c Fix SetLevels for makeStaticPtr 8b1cfea089faacb5b95ffcc3511e05faeabb8076 Extend CSE to handle recursive bindings 50411995641802568bb27c867afe804f91e0524c Combine identical case alterantives in CSE 2e077ccc736a0b2a622b7f42b7929966bddb4ded Inline data constructor wrappers in phase 2 only b868de53dd19f639c1070089ecff21948ff33e0d Make Specialise work with casts c767ae5f04a09ef71dcb8f67a17225a52c2cc5d2 Stop uniques ending up in SPEC rule names b49ed1f0102f93ca7f62632c436b41bd240b501f Occurrence-analyse the result of rule firings 607a735dfb99bb8f0edf466ccb01e732218c42ec Add -fspec-constr-keen 67a0c1872c0515f1f12ea68097a84e02da92f45b Refactor floating of bindings (fiBind) e90f4d7c6d3003039fa1647a3da3dafcaa75527b More tracing in SpecConstr Much to my surprise, we get some jolly nice improvements in compiler perf: 3% perf/compiler/T5837.run T5837 [stat too good] (normal) 7% perf/compiler/parsing001.run parsing001 [stat too good] (normal) 9% perf/compiler/T12234.run T12234 [stat too good] (optasm) 35% perf/compiler/T9020.run T9020 [stat too good] (optasm) 9% perf/compiler/T3064.run T3064 [stat too good] (normal) 13% perf/compiler/T9961.run T9961 [stat too good] (normal) 20% perf/compiler/T13056.run T13056 [stat too good] (optasm) 5% perf/compiler/T9872d.run T9872d [stat too good] (normal) 5% perf/compiler/T9872c.run T9872c [stat too good] (normal) 5% perf/compiler/T9872b.run T9872b [stat too good] (normal) 7% perf/compiler/T9872a.run T9872a [stat too good] (normal) 5% perf/compiler/T783.run T783 [stat too good] (normal) 35% perf/compiler/T12227.run T12227 [stat too good] (normal) 20% perf/compiler/T1969.run T1969 [stat too good] (normal) 5% perf/should_run/lazy-bs-alloc.run lazy-bs-alloc [stat too good] (normal) 5% perf/compiler/T12707.run T12707 [stat too good] (normal) 4% perf/compiler/T3294.run T3294 [stat too good] (normal) 1.5% perf/space_leaks/T4029.run T4029 [stat too good] (ghci) So what is left? I have sunk so much time into this and am still not QUITE out of the woods. I was left with Unexpected failures: codeGen/should_compile/debug.run debug [bad stdout] (normal) concurrent/should_run/T4030.run T4030 [bad exit code] (normal) I'm re-validating having pulled from HEAD, but I THINK that's all. Now * I don't know how to Phab these individually * I have not sweated through which patch is responsible for which perf improvments. Maybe Gipeda can tell? * I have not put each error message change with the correct patch. I don't know how much that matters. So this is to say: anything you guys can do to help get this actually Done would be really helpful. I'm out of time till Monday at least. It would be great to collect those performance improvements! Thanks! Simon

4 6

Static data and RULES
by David Feuer 18 Feb '17

18 Feb '17

Ben Gamari and Reid Barton are interested in making it cheaper for static data to pass through simplification. The basic idea is that if a term is already made entirely of data constructors and literals, then there's nothing left to optimize. However, RULES are allowed to match on data constructors and it would be nice to let that keep happening. But on the other hand, RULES are apparently (according to Duncan Coutts) already broken for strict data constructors, because they have workers and wrappers. My thought: let's allow phased INLINE and NOINLINE pragmas for data constructors. The default would be INLINE. The ~ phase choice would not be available: once inline, always inline. Semantics ~~~~~~~~~~ For all constructors: If a constructor is allowed by pragmas to inline in a certain phase, then in that phase terms built from it can be considered static. Once static, always static. If a constructor is not allowed to inline in a certain phase, terms built from it will be considered non-static. After demand analysis and worker/wrapper, all constructors are considered inline. For strict constructors: A strict constructor wrapper prohibited from inlining in a certain phase simply will not. Strict constructor wrappers will all be allowed to inline after demand analysis and worker/wrapper. This matches the way we now handle wrappers actually created in that phase. Syntax: For GADT syntax, this is easy: data Foo ... where {-# INLINE [1] Bar #-} Bar :: ... For traditional syntax, I think it's probably best to pull the pragmas to the top: {-# NOINLINE Quux #-} data Baz ... = Quux ... | ...

6 14

RE: Trac #13255
by Simon Peyton Jones 17 Feb '17

17 Feb '17

I've just rebuilt that branch from scratch. I see Unexpected failures: /tmp/ghctest-q4hnbi/test spaces/./codeGen/should_run/cgrun057.run cgrun057 [bad stderr] (profasm) /tmp/ghctest-q4hnbi/test spaces/./profiling/should_run/T2592.run T2592 [bad stderr] (profasm) /tmp/ghctest-q4hnbi/test spaces/./profiling/should_run/scc001.run scc001 [bad profile] (profasm) (I wish the test suite trimmed off those long paths in the summary...grr) Of these * T2592 is the strange repeated heap-exhaustion thing * scc001 looks like a harmless re-ordering but I don't know why * cgrun057 has this diff -*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: +*** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: I guess harmless. Thanks simon From: Simon Peyton Jones Sent: 17 February 2017 15:12 To: Ben Gamari <ben(a)well-typed.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: Trac #13255 Ben I have pushed a fix for #13255 (blocking the release) to wip/T13255-spj It contains a series of patches, of which the important one is the last. But Phabbing them exceeded my skill level. I'm rebuilding yet again, but I got a couple of strange testsuite errors. Here is one T2592: Heap exhausted; T2592: Current maximum heap size is 1048576 bytes (1 MB). T2592: Use `+RTS -M<size>' to increase it. +T2592: Heap exhausted; +T2592: Current maximum heap size is 1048576 bytes (1 MB). +T2592: Use `+RTS -M<size>' to increase it. Why would the identical message (from the RTS) now be printed twice? I'm baffled. Maybe a clean build will help. Meanwhile I'm out of time. Can I hand the branch off to you to complete and merge? Get back to me if problems. Simon

1 0

Trac #13255
by Simon Peyton Jones 17 Feb '17

17 Feb '17

Ben I have pushed a fix for #13255 (blocking the release) to wip/T13255-spj It contains a series of patches, of which the important one is the last. But Phabbing them exceeded my skill level. I'm rebuilding yet again, but I got a couple of strange testsuite errors. Here is one T2592: Heap exhausted; T2592: Current maximum heap size is 1048576 bytes (1 MB). T2592: Use `+RTS -M<size>' to increase it. +T2592: Heap exhausted; +T2592: Current maximum heap size is 1048576 bytes (1 MB). +T2592: Use `+RTS -M<size>' to increase it. Why would the identical message (from the RTS) now be printed twice? I'm baffled. Maybe a clean build will help. Meanwhile I'm out of time. Can I hand the branch off to you to complete and merge? Get back to me if problems. Simon

2 1

GHC 8.2.1 status
by Ben Gamari 17 Feb '17

17 Feb '17

Hello everyone, It has been a bit over a week since the last update regarding 8.2.1. At the moment we are on the final stretch leading up cutting the branch. Over the last week I have been cleaning up a variety of odds and ends around the tree, bumping core libraries, merging some last patches, smoke testing, and putting the final touches on the Typeable branch which will be merged shortly. However, during testing against Hackage I found a regression (#13255) due to the recent join-points merge that needs to be addressed before we can consider cutting a release candidate. This will likely be resolved soon, which should allow us to release a source release by mid-to-late next week (assuming no further regressions are found). Cheers, - Ben

1 0

Re: Better perf for haddock.base, haddock.Cabal (f4aa998)
by Joachim Breitner 16 Feb '17

16 Feb '17

Hi, Am Donnerstag, den 16.02.2017, 17:46 +0000 schrieb git(a)git.haskell.org: > commit f4aa9984790332a908e8b1321d00a839fb42c3ea > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Feb 16 17:44:58 2017 +0000 > > Better perf for haddock.base, haddock.Cabal > > I think this is due to > commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Feb 16 09:42:32 2017 +0000 > > Improve checking of joins in Core Lint > > Improvement is around 5%. no, https://perf.haskell.org/ghc/#revision/fc9d152b058f21ab03986ea722d0c94688b9… clearly points to this commit: commit fc9d152b058f21ab03986ea722d0c94688b9969f Author: Simon Peyton Jones < simonpj(a)microsoft.com > Date: Thu Feb 16 09:41:55 2017 +0000 Comments and tiny refactor only Which is not just a refactoring. If you look at the diff, e.g. at https://phabricator.haskell.org/rGHCfc9d152b058f21ab03986ea722d0c94688b9969f you will see that after your change, the “one shot arguments according to the environment” are no longer counted towards n_val_args in fun_uds and is_exp. And it seems they should not! Is that something you understand and can explain in a note? I guess https://phabricator.haskell.org/D3089 was merged a bit prematurely in that respect.¹ Greetings, Joachim ¹ There is a workflow problem with Phab’s DR: * A creates a new DR. * B requests changes. DR now in state “revision needed” * C requests changes. DR still in state “revision needed” * A makes changes. DR now in state “needs review” * C looks at the changes and finds his concern addressed and accepts the revision. DR now in state “accepted”. * G comes along, sees a DR in state “accepted” and lands it. Problem: B did not have the chance to check the new revision. -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

3 3

Re: Static data and RULES
by David Feuer 16 Feb '17

16 Feb '17

The vast majority would have no pragma, or at least wouldn't have an unphased NOINLINE pragma, so they would typically inline before demand analysis anyway. David FeuerWell-Typed, LLP -------- Original message --------From: Joachim Breitner <mail(a)joachim-breitner.de> Date: 2/16/17 5:20 PM (GMT-05:00) To: ghc-devs(a)haskell.org Subject: Re: Static data and RULES Hi, Am Donnerstag, den 16.02.2017, 17:12 -0500 schrieb David Feuer: > Strict constructor wrappers will all be allowed to inline after > demand analysis and worker/wrapper. This matches the way we now > handle wrappers actually created in that phase. I am worried that DmdAnal will be less effective the code it sees does not have the wrappers of strict constructors already inlines. It may be that the strictness signature of the wrapper is sufficient to make up for this, but I am not sure. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

1 0

FW: [Diffusion] [Build Failed] rGHC6bab649bde65: Improve checking of joins in Core Lint
by Simon Peyton Jones 16 Feb '17

16 Feb '17

perf/haddock.base and haddock.Cabal have improved, hence failure here.. am building with HADDOCK_DOCS on. If someone else gets there first, be my guest From: noreply(a)phabricator.haskell.org [mailto:noreply@phabricator.haskell.org] Sent: 16 February 2017 16:08 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: [Diffusion] [Build Failed] rGHC6bab649bde65: Improve checking of joins in Core Lint Harbormaster failed to build B13964: rGHC6bab649bde65: Improve checking of joins in Core Lint! BRANCHES master USERS simonpj (Author) COMMIT https://phabricator.haskell.org/rGHC6bab649bde65 EMAIL PREFERENCES https://phabricator.haskell.org/settings/panel/emailpreferences/ To: simonpj, Harbormaster

1 0

Convincing GHC not to produce unfoldings during simplification
by Ben Gamari 16 Feb '17

16 Feb '17

I'm currently trying to get the interface file bulk imposed by TTypeable down. The branch will currently produce two top-level bindings for each TyCon. For instance, given the type, data Proxy (a :: k) = Proxy the branch will produce (ignoring the promoted datacon for a moment), $tcProxy :: TyCon $tcProxy = GHC.Types.TyCon fpr1 fpr2 -- fingerprints $trModule (GHC.Types.TrNameS "Proxy"#) 1 krep_aebr krep_aebr :: KindRep krep_aebr [InlPrag=NOINLINE CONLIKE] = GHC.Types.KindRepFun (GHC.Types.KindRepVar 0) (GHC.Types.KindRepTYPE GHC.Types.LiftedRep) Note that the KindRep has been marked as NOINLINE; I do this intentionally as these things can grow quite large (consider, for instance, the kind of a promoted tuple constructor). This is especially true as the simplifier tends to float out the constituents of the KindRep. After the first simplifier phase we end up with, krep_sebQ :: GHC.Types.KindRep [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] krep_sebQ = GHC.Types.$WKindRepVar (GHC.Types.I# 0#) krep_sebR :: GHC.Types.KindRep [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] krep_sebR = GHC.Types.$WKindRepTYPE GHC.Types.LiftedRep krep_aebr [InlPrag=NOINLINE CONLIKE] :: GHC.Types.KindRep [LclId, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] krep_aebr = GHC.Types.KindRepFun krep_sebQ krep_sebR This means that GHC will now include each of the bindings floated out from krep_aebr in the interface file, despite the NOINLINE pragma, as they are all depended upon by the exported $tcProxy through their unfoldings. This is Quite Bad. I have observed that the floated bindings are not included in the interface file with -O0. Moreover, the core2core output clearly shows the unfoldings being added after the first simplifier phase. I haven't yet determined where in the simplifier these unfoldings are being introduced, but if anyone has ideas I'd love to hear them. Cheers, - Ben

2 3