- ghc-devs - Haskell.org

debug output
by Simon Peyton Jones 24 Apr '17

24 Apr '17

mk/flavours/validate.mk has GhcStage2HcOpts = -O -dcore-lint GhcLibHcOpts = -O -dcore-lint How can I override these in my validate.mk? E.g. GhcLibHcOpts += -ddebug-output does not work. Thanks. One should really be able to override anything. Simon

3 4

Re-compiling wired-in packages
by Shao Cheng 24 Apr '17

24 Apr '17

Dear friends, I'm trying to implement a new codegen for ghc, starting by using the ghc api to compile modules to STG/Cmm. In order to support importing Prelude, I also need the STG/Cmm representations of wired-in packages like base, ghc-prim, etc, and I guess that means I need to re-compile them. I can roughly think of two approaches: * Load the `ModIface` of wired-in packages, which are tidied Core modules, and convert to STG/Cmm * Get the library sources from ghc repo and launch a regular compilation. I haven't succeeded in either approach. For the first one, I haven't found a way to convert `ModIface` of external package to regular compilation targets; for the second one, regular "cabal installs" won't do the trick, seems compiling wired-in packages require quite some magic. What is the preferred way of re-compiling wired-in packages and retrieving their STG/Cmm representations? Thank a lot. Cheers, Shao Cheng

2 1

Harbormaster out to sea?
by Richard Eisenberg 24 Apr '17

24 Apr '17

I've posted a few diffs today, but Harbormaster seems stalled in checking them: - https://phabricator.haskell.org/D3424 - https://phabricator.haskell.org/D3487 - https://phabricator.haskell.org/D3490 Do you have any insight into this? Thanks! Richard

2 1

GHC Build System & Cabal
by Moritz Angermann 21 Apr '17

21 Apr '17

Dear friends, I’m currently exploring the possibility to build two versions of base similar to how we build various ways of the rts. The reasons for doing this won’t add much to the discussion. Reading https://ghc.haskell.org/trac/ghc/wiki/Building/Architecture/Idiom/Cabal I find the following: > For the GHC build system we need to extract that metadata and use > it to build the package. which leaves me wondering why that is? Initially I expected we’d just shell out and let cabal do the configuration and building of .cabal’ised packages. But it seems to be the case that we sidestep cabal for building ghc. Can someone shed some light on the reasoning behind this? Cheers, Moritz

2 1

Re: [Diffusion] [Raised Concern] rGHC751996e90a96: Kill off complications in CoreFVs
by Joachim Breitner 18 Apr '17

18 Apr '17

[CC’ing ghc-dev in case others are also curious about how to navigate Gipeda.] Hi, Am Donnerstag, den 13.04.2017, 08:40 +0000 schrieb Simon Peyton Jones: > Thanks for noticing this! I will investigate. > > But where do you see this? > · at perf.haskell.org I see “GHC” and “Gipeda”. It’s not > obvious which I want. You want the GHC Dashboard, as you guessed correctly. > · Clicking GHC shows me some “recent commits”. The first > three are from a few hrs ago; then the next is 8 days ago. Can’t be > right! It only shows interesting commits. Interesting ones are the most recent ones and all with significant changes. If you want to see all, press the “=” button in the top-right corner. > · There is no key to tell me what the little symbols mean – I > may have known once but I don’t know. A key would be terrific, or > even a link to a key. The symbols next to the three numbers on the right in the table? They are: * number of benchmarks * number of benchmarks improved * number of benchmarks regressed Maybe I should remove the first one, it is not very useful Hovering these icons show you which benchmarks changed, and by how much. > · Clicking on the offending patch (which does show), I see > the n-body complaint, which is good. But there is also > “testsuite/unexpected stats, which is mysterious… clicking on it > yields no more info. There is a “view buildlog” link that I use to investigate such cases. It goes to https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/751996e90a9… which shows bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T13056(optasm) bytes allocated: 440548592 +/-5% Lower bound T13056(optasm) bytes allocated: 418521162 Upper bound T13056(optasm) bytes allocated: 462576022 Actual T13056(optasm) bytes allocated: 417666128 Deviation T13056(optasm) bytes allocated: -5.2 % *** unexpected stat test failure for T13056(optasm) Probably some creep, given how close it is to cut-off percentage. According to https://perf.haskell.org/ghc/#graph/tests/alloc/T13056 this has been stable in the last 50 commits (sorry, still no way to view these graph for any other time interval). > · If compile times went up, would that show up anywhere > (except in testsuite results)? Only if it changes the total time of running make, or if it affects the allocations of a compiler perf test case. We currently have no reliable compilation time benchmarks (which would require _compiling_ stuff NofibRun times). 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

2 2

Re: Where do I start if I would like help improve GHC compilation times?
by Johannes Waldmann 18 Apr '17

18 Apr '17

> it would be quite helpful if `pretty` > gained a special-case for the infinite band-width case Absolutely +1 this. Not "pretty" but similar: https://github.com/jwaldmann/wl-pprint-text/commit/7843d96db57ab01c0be336a5… - J.W.

1 0

Where do I start if I would like help improve GHC compilation times?
by Alfredo Di Napoli 18 Apr '17

18 Apr '17

Hey folks, maybe I’m setting up for something too ambitious for me, but I would like to take an active stance to the overlasting “GHC compilation times are terrible” matter, instead of simply stare at the screen with despair whenever GHC compiles a sufficiently large Haskell program ;) To make this even more interesting, I have never contributed to GHC either! The max I have pushed myself into was 2 years ago when I successfully built GHC head from source and tried to fix an Haddock “easy” ticket I don’t even recall (full disclosure, eventually I didn’t :D ). Specifically, I would love community recommendations & guidance about: 1. Is this simply too daunting for somebody like me? Maybe is better to first start contributing more regularly, take confidence with the code base AND then move forward? 2. Are compilation times largely dependant from the target platform (I’m on Darwin) or there is something which can be done “globally” so that the benefits can be experienced by everybody? 3. Is there any recommended workflow to profile GHC compilation times? Is there any build flavour one should prefer when doing so? (Maybe the full, slowest one?) Thanks in advance for taking the time reading this mail, and have a nice weekend! Alfredo

7 17

downloads.haskell.org unavailable for a bit
by Ben Gamari 15 Apr '17

15 Apr '17

Hello all, Unfortunately, due to a botched rsync, the tarballs on downloads.haskell.org will be unavailable for a few hours. I'm currently working on restoring the 8.0.2 tarballs first to ensure that they remain available to users. I will follow up with status updates as they come. Many apologies for the inconvenience. Cheers, - Ben

1 2

ghc-stage2 —interactive segfaults on Mac OS X 10.11.6 (build flavour = prof)
by Alfredo Di Napoli 15 Apr '17

15 Apr '17

Hey all, I’m trying to compile GHC HEAD (cloning from master) with the `prof` build flavour on a Mac OS X 10.11.6 machine and I have noticed that, despite ghc-stage2 works as expected, when invoked with —interactive it starts before crashing with a segmentation fault: ``` ☁ compiler [master] ⚡ ../inplace/bin/ghc-stage2 --interactive GHCi, version 8.3.20170413: http://www.haskell.org/ghc/ :? for help [1] 79176 segmentation fault ../inplace/bin/ghc-stage2 --interactive ``` Did it happen to somebody else or it’s just me? Shall I try throwing gdb at it to try and see what’s going on? Thanks, Alfredo

3 5

Join points and loopificaiton
by Simon Peyton Jones 13 Apr '17

13 Apr '17

Luke Kavon Farvardin is here as an intern, mainly working on LLVM backend stuff. But he knows a lot about CPS etc and he'd read our paper. In talking about it, we realised a new Join Point Win! I've written it up in https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Loopification under "New idea: use join points". Let's do it! Ticket here: https://ghc.haskell.org/trac/ghc/ticket/13567 Simon

2 1