- ghc-devs - Haskell.org

RE: msys2 64 bit: help help!
by Andrey Mokhov 27 Jun '16

27 Jun '16

Hi Simon, > 3. After this step, starting a shell failed altogether with "c:/msys64/mingw64_shell.bat is > not recognised as an internal or external command". And sure enough, there is no such file. > Presumably it existed in step 1. So perhaps step 2 deleted it? > [...] > 4. As you mention, I then tried msys2_shell.cmd. It worked -- with a noticeable delay of 5 > seconds or so. I've also just got a new Win10 laptop and had the same issue with missing mingw64_shell.bat during msys2 install. I solved it by creating mingw64.bat with the following contents: msys2_shell.cmd -mingw64 -mintty I deleted all old shortcuts and use this script instead. Everything seems to work fine -- can build GHC. Cheers, Andrey

2 1

msys2 64 bit: help help!
by Simon Peyton Jones 27 Jun '16

27 Jun '16

Friends, esp Tamar, I am in happy possession of a new Surface Book, running Windows 10, which is delightful - except that I can't make the msys64 installation work, which is crucial for GHC. Can any of you help? * I install it from here: https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/, which seems to be the canonical place. The actual 64-bit exe seems to be msys2-x86_64-20160205.exe. * Installation goes fine * But when I launch the "MinGW-w54 Win64 shell" from the Start menu, the screen flashes as if it is briefly putting up a window, but then the window disappears. * Each time I do this the task manager shows that there is another running 'mintty.exe'. But it has no visible window Does anyone have any idea what I can do or how I can investigate? I can't do any GHC development without this! Thanks Simon

3 2

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