- ghc-devs - Haskell.org

Bug: GHC creates incorrect code which throws <<loop>>
by Yongqian Li 23 Apr '15

23 Apr '15

Hi all, I wanted to bring to your attention this bug, https://ghc.haskell.org/trac/ghc/ticket/10218 , which I filed about two days ago but hasn't gotten any replies to yet. In my opinion, this is a rather serious bug since GHC is producing incorrect code. While there is a workaround, it makes my program take about 2 hours to compile. Since reporting the bug, I've also seen "strange closure type" exceptions, which I believe are also caused by this bug, although I do not have a test case. Based on my limited understanding of GHC internals, I suspect the problem lies in how type class dictionaries are looked up at run time, as the problem disappears if GHC can fully resolve the types. Can others see if they can reproduce this bug? If there is any way I can help, please let me know. Sincerely, Yongqian Li

5 5

OS X bindist
by Andrew Farmer 23 Apr '15

23 Apr '15

Forgive me if this has been answered somewhere, but is there an officially sanctioned bindist of 7.10.1 for OS X yet? The page I usually visit [1] doesn't list one yet. Thanks! Andrew [1] https://www.haskell.org/ghc/download_ghc_7_10_1

5 4

Fwd: Re: Branchless implementation for literal case – is it worth it?
by Niculae Ionita 20 Apr '15

20 Apr '15

Sorry, I forgot to answer to the list. If the code is already there and some architectures can profit of it, especially in inner loops - why not just make it an optimisation flag? Nicu Am 20.04.2015 um 16:41 schrieb Joachim Breitner: > Hi, > > Am Montag, den 20.04.2015, 16:29 +0200 schrieb Sven Panne: >> 2015-04-19 9:44 GMT+02:00 Joachim Breitner<mail(a)joachim-breitner.de>: >>> [...] So my question to the general audience: Is such branchless code really >>> better than the current, branching code? Can someone provide us with an >>> example that shows that it is better? Do I need to produce different >>> branchless assembly? [...] >> Just a few war stories regarding this from the trenches (= Chrome's >> JavaScript JIT): > thanks a lot. > > The conclusion I draw from your mail, at last for our case, is: > Don’t bother (and keep the compiler code simple). Is that a correct > reading? > > Greetings, > Joachim > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 2

Branchless implementation for literal case – is it worth it?
by Joachim Breitner 20 Apr '15

20 Apr '15

Dear devs, in https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that code like f :: Int -> Bool f a = case a of 1 -> True 5 -> True 8 -> True 9 -> True 11 -> True 19 -> True _ -> False {-# NOINLINE f #-} should not compile to a series of conditional jumps, but rather a branchless code akin to let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9 `orI#` a ==# 11 `orI#` a ==# 19 case p of 1 -> do_something 0 -> do_something_else Subsequently, I refactored the way we produce Cmm code from STG, opening the possibility to implement this optimization at that stage¹. But when I then added this implementation, I could not measure any runtime improvement, see https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15 So my question to the general audience: Is such branchless code really better than the current, branching code? Can someone provide us with an example that shows that it is better? Do I need to produce different branchless assembly? If it is not better, I can again refactor the switch generation and simplify it a bit again. Hmm, only now I see that rwbarton has replied there. Not sure why I missed that. Anyways, more voices are welcome :-) Greetings, Joachim ¹ This should not preclude an implementation on the Core level, which SPJ preferred. But I improved other aspects of the code generation as well, so this is worthwhile on its own. -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

8 9

Trac is soul-extinguishingly slow
by Richard Eisenberg 18 Apr '15

18 Apr '15

Hi devs, Trac isn't working again. In an entirely unscientific study, 4 out of the last 5 sessions where I tried to access Trac, I was unable to. If ghc.haskell.org is getting slammed, is it possible to disconnect Trac from that name and instead just publish some IP address until we have things working better? (Apologies if that sentence doesn't make any sense at all. I've dealt very little with these sorts of issues.) Thanks, Richard

4 5

RE: [Haskell] Haskell on Windows instructions - is MinGHC version update needed?
by Simon Peyton Jones 16 Apr '15

16 Apr '15

Fwding to the GHC Windows Task force, who will doubtless know what to do. Simon | -----Original Message----- | From: Haskell [mailto:haskell-bounces@haskell.org] On Behalf Of Howard B. | Golden | Sent: 15 April 2015 17:51 | To: haskell(a)haskell.org | Subject: [Haskell] Haskell on Windows instructions - is MinGHC version | update needed? | | Hi, | | Currently, the Haskell website's Windows download page | (https://www.haskell.org/downloads/windows) offers two alternatives, | MinGHC and Haskell Platform. The MinGHC alternative has a link to MinGHC- | 7.8.3 installer. Should this be updated to MinGHC-7.8.4? I ask this | because Long Term Support Haskell 2.3 is now using GHC 7.8.4. If you want | to update the link, you only need to change the URL from 7.8.3 to 7.8.4. | | Howard | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

4 4

DocBook to AsciiDoc
by Daniel Bergey 16 Apr '15

16 Apr '15

I just read that GHC wants to convert the manual to asciidoc. If no one else has yet volunteered to do this, I hearby volunteer myself. I haven't contributed to the GHC manual before, nor to GHC. I guess that I will need to learn my way around Phabricator? I expect to be proof-reading sections that I haven't read before, about GHC features I don't use. I don't expect this to be a problem, since the goal is just to match the current HTML output. I do have some experience with DocBook, Asciidoc, and Pandoc, which should be helpful. Is there anything I should convert that isn't in under the users_guide folder?[1] It looks as though the users guide gets frequent commits.[2] Does one `arc diff` per file, approximately, sound reasonable, to keep merge conflicts manageable? Anything else I should know before I begin? Who to list as reviewers? A Trac ticket to link all the asciidoc commits together? Thanks, Daniel Footnotes: [1] http://git.haskell.org/ghc.git/tree/HEAD:/docs/users_guide [2] http://git.haskell.org/ghc.git/history/HEAD:/docs/users_guide

2 1

ghc-7.10 branch regression
by Erik de Castro Lopo 16 Apr '15

16 Apr '15

Hi all, It seems that commit 42448e3757 from git HEAD has been pulled into the ghc-7.10 branch as commit 07da52ce2d. This is problematic because that patch puts in a *requirement* for llvm-3.6 (which is good for git HEAD) but the llvm backend code in the ghc-7.10 branch does not compiler with llvm-3.6. Specifically, on armhf I get: /usr/bin/opt-3.6: /tmp/ghc16494_0/ghc16494_2.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} Furthermore, validating the ghc-7.10 branch on amd64-linis results in 16 unexpected failures (i'm currenty in the process of validating this branch with the problematic commit reverted). At this point we need to decide whether: a) Require llvm-3.6 for 7.10.2 and later. or b) Revert commit 07da52ce2d in the ghc-7.10 branch and continue to use llvm-3.5 for the 7.10 series. For option a) we would need to do the following: * Pull in 5d5abdca31 from git HEAD that upgrades the LLVM backend to support llvm-3.6 only. * Pull in 485dba86 from git HEAD that updates the configure stuff and is really the second part of 42448e3757. For option b) we would need to do the following: * Revert 07da52ce2d from ghc-7.10 * Apply the patch mentioned here: https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11 At this point, my personal preference would be a). For me, git HEAD using llvm-3.6 has been working a lot better on armhf and arm64 than the ghc-7.10 branch. Ticket #10234 has been set to 'merge' status to refect this. Cheers, Erik PS : I would have raised another ticket about this, but I think the problem here was actually caused by too many tickets and too many commits being involved. Interesting tidbits in case anyone is interested: * On armhf, building the ghc-7.10 branch fails because we a generating LLVM IR code targeted for llvm-3.5 and trying to compile it with llcm-3.6. * The ghc-7.10 validates (with 16 unexpected failures) in x86 variants because validation uses the NCG to build the compiler and ignores the requirement for llvm-3.6, and then bindisttest compiler just uses "llc" and "opt" (in git HEAD this difference between the compiler configure script and the binary-dist configure script is fixed in 485dba86 and it is fixed in ghc-7.10 by the patch in https://ghc.haskell.org/trac/ghc/ticket/10234#comment:11) -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4 6

Building patches that change format of interface files
by Jan Stolarek 15 Apr '15

15 Apr '15

GHC Devs, Once I compile GHC I use the "cd ghc; make 2" trick to re-compile any changes. That however does not work if my code changes modify the format of interface files - the resulting compiler is unusable. In fact the only way to get a working compiler after interface format change that I am aware of is to rebuild everything from scratch. Needless to say, this takes a lot of time. Is there a better way? I'd like to test D841 but if this means rebuilding everything then I'll have to pass. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system.

3 3

Slower Compilation on GHC 7.8.4 (vs. 7.6.3)
by Ozgun Ataman 15 Apr '15

15 Apr '15

Hello, Apologies upfront for the long post below, but I thought our experience on this particular point might be worth sharing. I present some observations first and then mention the particular problem around "cabal repl" facilitated development workflow. Any ideas/feedback on the latter point would be much appreciated and please let me know if there are other metrics, info or output I can produce here for further investigation/clarification. Recently at work, we upgraded a decent size project from GHC 7.6.3 to GHC 7.8.4 and as a result observed a very significant slowdown in compile times. Code changes were very minimal and should not be a factor. Any mistakes below are mine, but I can fairly confidently say that there is a visible-to-the-eye slowdown in compile times. We made a few measurements to quantify the issue and here is the data: - This project has 220 direct modules (non-dependency) that are compiled with each "cabal build" and we always use sandboxes - Tests were performed on OS X, though we saw similar results on Linux - Single threaded (-j=1) wall-clock compile time has gone up by around 30% for the overall project - With O1 and -j=N, the overall wall-clock time is approximately the same (around 8 min), but the CPU time spent is a staggering 7.5X higher (!) - With O0 and -j=N the overall wall-clock time is 40% higher, but the CPU time spent is a staggering 7.5X higher (!) - With -O0, "cabal repl" load times have gone up by a staggering 2.5X (!) - 7.8.4: 3 min. 35 seconds - 7.6.3: 1 min. 2 seconds - Measuring compile times for individual modules, we see that those that are heavily loaded with lots of types, TH-facilitated type and typeclass derivations and those that contain large "blobs" of values directly at the top level now take much longer to compile: - We have 10 modules that each take over 10 seconds - We have 3 modules that each take over 35 seconds - Sidenote observation: In general, parallel builds with -j appear to cause a very significant overhead under the "system" part of timing: - Example with 7.6.3, O0: cabal build 140.57s user 13.25s system 100% cpu 2:33.70 total - Example with 7.8.4, O0: cabal build 507.83s user 655.43s system 549% cpu 3:31.59 total The main hurt here has been the infeasibility of using "cabal repl / ghci" fast-feedback style development (via emacs, vim, command-line, etc.), since: - Unlike "cabal build", "cabal repl" re-compiles from scratch with every invocation ":l App.Foo.Bar", which itself is the necessary first step when starting to hack on a module (we can then use :r to somewhat help the situation) - The slowdown is about 2.5X as stated above: What used to take a minute now takes 3.5 minutes. - cabal repl does not seem to benefit from -j at all - cabal repl 7.8.4 appears to be hurt particularly by the heavier modules - The heavier modules are often at the top of the compile tree (types, derivations, etc) and are practically loaded on the critical path all the time Let me know if I'm missing anything here and any/all feedback is much appreciated! Cheers, Oz

5 6