April 2020 - ghc-devs

scavenge_one failures on BCO objects
by chessai . 10 Apr '20

10 Apr '20

Hi devs, A coworker is experiencing sporadic failures when reloading our project in GHCi, with ``` ghc: internal error: scavenge_one: strange object 23 (GHC version 8.6.5 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: repl failed for mercury-web-backend-0.0.0. The build process terminated with exit code -6 ``` upon a quick inspection it seems that scavenge_one inspects the type of the object, but has no case for BCO (which is 23). I'm guessing there's something weird going on here since this doesn't happen deterministically. I don't have a good intuition for how this scavenging should work for BCO's, or if it should even be possible for BCO's to appear here (i.e. this is a symptom of some other bug). Any thoughts? Thanks

2 1

hadrian.settings recipes
by Ben Gamari 09 Apr '20

09 Apr '20

Hi everyone, As you may know, Hadrian's analogue to the make build system's mk/build.mk is hadrian.settings file. While the new mechanism is quite flexible, I often find myself having to look up recipes from previous builds to accomplish common tasks. To try to improve this situation I've started collecting the snippets I need most often on the Wiki [1]. I would invite anyone else who has something to add to do so. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian#hadriansettings

1 0

Safe primops
by Simon Peyton Jones 09 Apr '20

09 Apr '20

Andreas, Simon, and other back-end-knowledgeable devs Can I draw your attention to this question? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3011#note_264584 It's about identifying which primops execute in-line without GC, and without thread-switching. Thanks Simon

1 0

Measuring compiler performance
by Simon Jakobi 08 Apr '20

08 Apr '20

Hi devs! I've recently started working on a few compiler perf related tickets, and wondered how to verify that a change actually has a positive impact on compiler performance. I first looked at the wiki for information on this, but didn't find much: https://gitlab.haskell.org/ghc/ghc/-/wikis/performance/compiler doesn't contain any information on how to measure compiler performance The best tip I found was the recommendation in https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-no-fib to compile nofib/spectral/simple/Main.hs. With -O0 and -O that takes respectively about 1.5s and 5s for me, so the effort is manageable. I've also done full nofib runs, but they take a very long time. A problem in this context is that reliable performance measurements require a quiet machine. Closing my browser, and turning off other programs is – in my perception – rather inconvenient, particularly when I have to do it for a prolonged time. Ideally I wouldn't have to perform these measurements on my local machine at all! Do you usually use a separate machine for this? _Very_ convenient would be some kind of bot whom I could tell e.g. @perf-bot compiler perf …or more concretely @perf-bot compile nofib/spectral/simple/Main.hs …or just @nofib-bot run … or something like that. I've noticed that CI now includes a perf-nofib job. But since it appears to run on a different machine each time, I'm not sure whether it's actually useful for comparing performance. Could it be made more useful by running it consistently on the same dedicated machine? Another question regarding performing compiler perf measurements locally is which build flavour to use: So far I have used the "perf" flavour. A problem here is that a full build seems to take close to an hour. A rebuild with --freeze1 takes ~15 minutes on my machine. Is this the right flavour to use? BTW what's the purpose of the profiled GHC modules built with this flavour which just seem to additionally prolong compile time? I don't see a ghc-prof binary or similar in _build/stage1/bin. Also, what's the status of gipeda? The most recent commit at https://perf.haskell.org/ghc/ is from "about a year ago"? Sorry for this load of questions and complaints! I do believe though that if work on compiler performance was a bit better documented and more convenient, we might see even more progress on that front. :) Cheers, Simon

6 7

Re: Uppercase OverloadedLabels
by Ryan Scott 08 Apr '20

08 Apr '20

No particular reason. There is an accepted GHC proposal to relax this restriction [1], as well as an accompanying GHC issue [2], but it has not yet been implemented. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0170-u… [2] https://gitlab.haskell.org/ghc/ghc/issues/11671

1 0

Targeting old Windows versions
by Andreas Klebinger 08 Apr '20

08 Apr '20

Hello devs, GHC is planning to use the Large Address Space mode of allocation for future releases on windows. See https://gitlab.haskell.org/ghc/ghc/issues/12576 This is a significant optimization for the GC and well tested as we use it on Linux already. However it will regress memory useage on versions of windows *older* than Windows 8.1/Sever 2012. Please let us know if you are targeting older versions than that either by responding to the mailing list, commenting on the ticket or contacting me directly if you have privacy concerns. Depending on how many people are affected by this change we might consider measures to reduce the impact. Cheers, Andreas

1 0

Uppercase OverloadedLabels
by Alejandro Serrano Mena 07 Apr '20

07 Apr '20

Dear Haskell-Café / GHC devs, Is there any reason why the `OverloadedHaskell` extension does not work with labels starting with an uppercase letter? Kind regards, Alejandro

1 0

Fusing loops by specializing on functions with SpecConstr?
by Alexis King 06 Apr '20

06 Apr '20

Hi all, I have recently been toying with FRP, and I’ve noticed that traditional formulations generate a lot of tiny loops that GHC does a very poor job optimizing. Here’s a simplified example: newtype SF a b = SF { runSF :: a -> (b, SF a b) } add1_snd :: SF (String, Int) (String, Int) add1_snd = second add1 where add1 = SF $ \a -> let !b = a + 1 in (b, add1) second f = SF $ \(a, b) -> let !(c, f') = runSF f b in ((a, c), second f') Here, `add1_snd` is defined in terms of two recursive bindings, `add1` and `second`. Because they’re both recursive, GHC doesn’t know what to do with them, and the optimized program still has two separate recursive knots. But this is a missed optimization, as `add1_snd` is equivalent to the following definition, which fuses the two loops together and consequently has just one recursive knot: add1_snd_fused :: SF (String, Int) (String, Int) add1_snd_fused = SF $ \(a, b) -> let !c = b + 1 in ((a, c), add1_snd_fused) How could GHC get from `add1_snd` to `add1_snd_fused`? In theory, SpecConstr could do it! Suppose we specialize `second` at the call pattern `second add1`: {-# RULE "second/add1" second add1 = second_add1 #-} second_add1 = SF $ \(a, b) -> let !(c, f') = runSF add1 b in ((a, c), second f') This doesn’t immediately look like an improvement, but we’re actually almost there. If we unroll `add1` once on the RHS of `second_add1`, the simplifier will get us the rest of the way. We’ll end up with let !b1 = b + 1 !(c, f') = (b1, add1) in ((a, c), second f') and after substituting f' to get `second add1`, the RULE will tie the knot for us. This may look like small potatoes in isolation, but real programs can generate hundreds of these tiny, tiny loops, and fusing them together would be a big win. The only problem is SpecConstr doesn’t currently specialize on functions! The original paper, “Call-pattern Specialisation for Haskell Programs,” mentions this as a possibility in Section 6.2, but it points out that actually doing this in practice would be pretty tricky: > Specialising for function arguments is more slippery than for > constructor arguments. In the example above the argument was a > simple variable, but what if it was instead a lambda term? [...] > > The trouble is that lambda abstractions are much more fragile than > constructor applications, in the sense that simple transformations > may make two abstractions look different although they have the > same value. Still, the difference this could make in a program of mine is so large that I am interested in exploring it anyway. I am wondering if anyone has investigated this possibility any further since the paper was published, or if anyone knows of other use cases that would benefit from this capability. Thanks, Alexis

5 16

Re: Building libraries with an in-place GHC
by Ryan Scott 06 Apr '20

06 Apr '20

Hi Simon, As #18018 says, you need to use head.hackage to reproduce it. This page [1] contains a rather short tutorial on how to use it, but Ben is currently drafting a more detailed tutorial on its use here [2]. This is what I use whenever building any Hackage library with GHC HEAD. Ryan S. ----- [1] https://ghc.gitlab.haskell.org/head.hackage/ [2] https://gitlab.haskell.org/ghc/homepage/-/merge_requests/29

1 0

Building libraries with an in-place GHC
by Simon Peyton Jones 06 Apr '20

06 Apr '20

Devs I want to reproduce #18018, but that needs me to build pandoc with my freshly-built HEAD. I tried this (below) but as you can see that didn't work. What should I do? Thanks Simon bash$ cabal install --with-compiler=/home/simonpj/code/HEAD-3/inplace/bin/ghc-stage2 --package-db=/home/simonpj/code/HEAD-3/inplace/lib/package.conf.d pandoc-2.9.2.1 Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: pandoc-2.9.2.1 (user goal) [__1] trying: zlib-0.6.2.1 (dependency of pandoc) [__2] trying: base-4.14.0.0/installed-4.14.0.0 (dependency of zlib) [__3] next goal: haddock-library (dependency of pandoc) [__3] rejecting: haddock-library-1.8.0 (conflict: base==4.14.0.0/installed-4.14.0.0, haddock-library => base>=4.7 && <4.14) [__3] skipping: haddock-library-1.7.0, haddock-library-1.6.0, haddock-library-1.5.0.1, haddock-library-1.4.5, haddock-library-1.4.4, haddock-library-1.4.3, haddock-library-1.4.2, haddock-library-1.4.1, haddock-library-1.2.1, haddock-library-1.2.0, haddock-library-1.1.1, haddock-library-1.1.0, haddock-library-1.0.1, haddock-library-1.0.0, haddock-library-1.6.1 (has the same characteristics that caused the previous version to fail: excludes 'base' version 4.14.0.0) [__3] fail (backjumping, conflict set: base, haddock-library, pandoc) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: pandoc, base, haddock-library, zlib Try running with --minimize-conflict-set to improve the error message. bash$ cabal --version cabal-install version 3.2.0.0 compiled using version 3.2.0.0 of the Cabal library

1 0