- ghc-devs - Haskell.org

RE: [Diffusion] [Build Failed] rGHCbb84ee44e30e: Improve pretty-printing of Avail
by Simon Peyton Jones 27 Jun '16

27 Jun '16

These failures are odd. One is this change in T8761 which I'm sure is not my fault. I saw that simonmar did some hFlush thing -- could that be it? Simon +++ ./T8761.run/T8761.comp.stderr.normalised 2016-06-24 15:00:22.975083533 +0100 @@ -1,3 +1,7 @@ +pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _) +pattern x1_0 Q2 x2_1 = ((x1_0, x2_1)) +pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where + Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3]) T8761.hs:(16,1)-(39,13): Splicing declarations do { [qx1, qy1, qz1] <- mapM (/ i -> newName $ "x" ++ show i) [1, 2, 3]; @@ -119,10 +123,6 @@ pattern Pup x <- MkUnivProv x pattern Puep :: forall a. forall b. Show b => a -> b -> (ExProv, a) pattern Puep x y <- (MkExProv y, x) -pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _) -pattern x1_0 Q2 x2_1 = ((x1_0, x2_1)) -pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where - Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3]) pattern T8761.P :: GHC.Types.Bool pattern T8761.Pe :: () => forall (a0_0 :: *) . a0_0 -> T8761.Ex pattern T8761.Pu :: forall (a0_0 :: *) . a0_0 -> a0_0 | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 24 June 2016 14:50 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Diffusion] [Build Failed] rGHCbb84ee44e30e: Improve pretty- | printing of Avail | | Harbormaster failed to build B10226: rGHCbb84ee44e30e: Improve pretty- | printing of Avail! | | BRANCHES | master, wip/rae | | USERS | simonpj (Author) | | COMMIT | https://phabricator.haskell.org/rGHCbb84ee44e30e | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, Harbormaster

2 1

RE: [commit: ghc] master: Accept new (lower) allocations for T7257 (15641b0)
by Simon Peyton Jones 27 Jun '16

27 Jun '16

Does anyone know what made T7257 better? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 22 June 2016 22:08 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Accept new (lower) allocations for T7257 | (15641b0) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.hask | ell.org%2ftrac%2fghc%2fchangeset%2f15641b07f1d3ccb5f35b4f31539ecceb5fb38 | c17%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c32fafc88b758 | 43148b2a08d39ae1ea3f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eLrMob | XyWHA691jI3t4pf0CbGybfrVqptmkpTDdtDI8%3d | | >--------------------------------------------------------------- | | commit 15641b07f1d3ccb5f35b4f31539ecceb5fb38c17 | Author: Simon Marlow <marlowsd(a)gmail.com> | Date: Wed Jun 22 20:54:59 2016 +0100 | | Accept new (lower) allocations for T7257 | | | >--------------------------------------------------------------- | | 15641b07f1d3ccb5f35b4f31539ecceb5fb38c17 | testsuite/tests/perf/should_run/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/should_run/all.T | b/testsuite/tests/perf/should_run/all.T | index caf4eff..3cb6f8e 100644 | --- a/testsuite/tests/perf/should_run/all.T | +++ b/testsuite/tests/perf/should_run/all.T | @@ -276,9 +276,10 @@ test('T7257', | [(wordsize(32), 989850664, 10), | # expected value: 1246287228 (i386/Linux) | # 2016-04-06: 989850664 (i386/Linux) no idea | what happened | - (wordsize(64), 1654893248, 5)]), | + (wordsize(64), 1414893248, 5)]), | # 2012-09-21: 1774893760 (amd64/Linux) | # 2015-11-03: 1654893248 (amd64/Linux) | + # 2016-06-22: 1414893248 (amd64/Linux, sizeExpr | fix) | stats_num_field('peak_megabytes_allocated', | [(wordsize(32), 217, 5), | # 2012-10-08: 217 (x86/Linux) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has | kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c32fafc88b75843 | 148b2a08d39ae1ea3f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=RftvNpBH | H7bw53EdhgnsdV%2f6M2LNgFVB1t7gCwOTT7A%3d

3 2

CMM-to-ASM: Register allocation wierdness
by Harendra Kumar 26 Jun '16

26 Jun '16

Hi, I am implementing unicode normalization in Haskell. I challenged myself to match the performance with the best C/C++ implementation, the best being the ICU library. I am almost there, beating it in one of the benchmarks and within 30% for others. I am out of all application level tricks that I could think of and now need help from the compiler. I started with a bare minimum loop and adding functionality incrementally watching where the performance trips. At one point I saw that adding just one 'if' condition reduced the performance by half. I looked at what's going on at the assembly level. Here is a github gist of the assembly instructions executed in the fast path of the loop, corresponding cmm snippets and also the full cmm corresponding to the loop: https://gist.github.com/harendra-kumar/7d34c6745f604a15a872768e57cd2447 I have annotated the assembly code with labels matching the corresponding CMM. With the addition of another "if" condition the loop which was pretty simple till now suddenly got bloated with a lot of register reassignments. Here is a snippet of the register movements added: # _n4se: # swap r14 <-> r11 => 0x408d6b: mov %r11,0x98(%rsp) => 0x408d73: mov %r14,%r11 => 0x408d76: mov 0x98(%rsp),%r14 # reassignments # rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx => 0x408d7e: mov %rbx,0x90(%rsp) => 0x408d86: mov %rcx,%rbx => 0x408d89: mov %rdx,%rcx => 0x408d8c: mov %rsi,%rdx => 0x408d8f: mov %rdi,%rsi => 0x408d92: mov %r8,%rdi => 0x408d95: mov %r9,%r8 => 0x408d98: mov %r10,%r9 => 0x408d9b: mov 0x90(%rsp),%r10 . . . loop logic here which uses only %rax, %r10 and %r9 . . . . # _n4s8: # shuffle back to original assignments => 0x4090dc: mov %r14,%r11 => 0x4090df: mov %r9,%r10 => 0x4090e2: mov %r8,%r9 => 0x4090e5: mov %rdi,%r8 => 0x4090e8: mov %rsi,%rdi => 0x4090eb: mov %rdx,%rsi => 0x4090ee: mov %rcx,%rdx => 0x4090f1: mov %rbx,%rcx => 0x4090f4: mov %rax,%rbx => 0x4090f7: mov 0x88(%rsp),%rax => 0x4090ff: jmpq 0x408d2a The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. Maybe this is because these are reusable blocks and the movement is necessary when used in some other path? Can this be avoided? Or at least avoided in a certain fast path somehow by hinting the compiler? Any pointers to the GHC code will be appreciated. I am not yet much familiar with the GHC code but can dig deeper pretty quickly. But before that I hope someone knowledgeable in this area can shed some light on this at a conceptual level or if at all it can be improved. I can provide more details and experiment more if needed. Thanks, Harendra

5 13

T8761 failing for ext-interp
by Richard Eisenberg 26 Jun '16

26 Jun '16

Hi Simon, Phab tells us that T8761 is failing for the ext-interp way, as of d2006d050e7a9111c0c448d6262f8994ef5761b7 (Run all TH tests with -fexternal-interpreter (#12219)). See https://phabricator.haskell.org/B10229 Thanks, Richard

3 6

Help on first ticket
by Richard Fung 24 Jun '16

24 Jun '16

Hello! I apologize if this isn't the right place to ask; if it isn't please steer me in the right direction. Would anyone be willing to advise me on my first ticket? I've been trying to work on it on and off but haven't made much progress on my own. It's ticket #9370: https://ghc.haskell.org/trac/ghc/ticket/9370 I think I understand the issue conceptually but I don't know where to look for the code that needs to be changed.. Thanks!

3 5

Testsuite cleaning
by Simon Peyton Jones 24 Jun '16

24 Jun '16

Thomas During debugging I often compile a single test program ghc -c T1969.hs But the new testsuite setup doesn’t remove .hi and .o files before running a test, so make TEST=T1969 says bytes allocated value is too low: … Deviation T1969(normal) bytes allocated: -95.2 % Reason? Compilation was not required! Non-perf tests fail in the same way +compilation IS NOT required *** unexpected failure for T11480b(normal) I’m sure this didn’t use to happen. It’s not fatal, because can manually remove those .o files, but it’s a bit of a nuisance. Might it be easy to restore the old behaviour? Thanks Simon

3 3

Does anyone know any easy-to-run compile-time benchmark suites?
by Ömer Sinan Ağacan 23 Jun '16

23 Jun '16

Hi all, I was wondering if anyone has or knows easy-to-run compile-time benchmarks? I'm looking for something like nofib -- ideally after a fresh build I should be able to just run `make` and get some numbers (mainly allocations) back.

3 2

isInvisible
by Simon Peyton Jones 23 Jun '16

23 Jun '16

Richard I have just spent an hour plumbing the torrid swamp of binder visibility. There is bad naming confusion. We have · Visible · Specified · Invisible The function isVisible returns True for Visible and False otherwise. But isInvisible returns True for Invisible and Specified. And partitionInvisibles, filterOutInvisibleTyVars, filterOutInvisibleTypes etc all treat Invisible and Specified the same. That is, it’s really filterOutInvisibleOrSpecifiedTypes which is terribly clumsy. Sometimes we need to pick up just the Inivisble args, and we don’t have a predicate for that (since isInvisible is taken), so you’ll see in Inst.top_instantiate we are reduced to saying (binderVisibility bndr == Invisible). It’s all very smelly. The trouble is that · In displayed types like (T a b), we display args that are Visible, but not Specified or Invisible · In visible type application like (f @t1 @t2) we can specify type args that are Visible or Specified but not Invisible. Urgh. The trouble is that “invisible” is not the negation of “visible”, which leads to all kinds of confusion. I wonder about changing to · Explicit · Specified · Implicit Then for display we display Explicit args only; for VTA we can specify Explicit or Specified args. So “not Explicit” doesn’t sound structurally like “Implicit” in the way that “not Visible” does sound like “Invisible”. Simon

2 4

Require -fexternal-interpreter support for future TH changes?
by Simon Marlow 23 Jun '16

23 Jun '16

*Background* A few months ago I added -fexternal-interpreter to GHC: - docs: http://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#gh… - wiki, rationale: https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi When -fexternal-interpreter is used, GHC runs interpreted code in a separate subprocess, and communicates with it using binary messages over a pipe. -fexternal-interpreter currently implements all of TH, quasi-quoting, annotations, and all the GHCi features except for some features of the debugger. It is also now implemented on Windows, thanks to Tamar Christina. *Proposal* I'd like to propose that going forward we commit to maintaining full support for -fexternal-interpreter, with a view to making it the default. Why? - -fexternal-interpreter will be a prerequisite for GHCJS support, so maintaining full support for TH in -fexternal-interpreter will ensure that everything that works with GHC works with GHCJS. - We will be able to make simplifications in GHC and the build system once -fexternal-interpreter is the default, because when compiling with -prof or -dynamic we won't have to compile things twice any more. - Ultimately we don't want to have two ways of doing everything, because that's harder to maintain. How? - I'll make all the TH and quasi-quoting tests run with and without -fexternal-interpreter, so it will break validate if one of these fails. *Why now?* There are some TH changes in the pipeline that will need special attention to work with -fexternal-interpreter. e.g. https://phabricator.haskell.org/D2286 and https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Introspective, so I'd like to raise it now so we can keep the issue in mind. Cheers Simon

4 11

How bad would it be for containers to depend on transformers?
by David Feuer 22 Jun '16

22 Jun '16

Currently, containers does not depend on transformers, so it has to duplicate its functionality or just do without. Since transformers is also a GHC boot package, I believe it should be feasible to make containers depend on it. To what extent would that reduce parallelizability of GHC builds or otherwise make people mad? David

2 1