- ghc-devs - Haskell.org

Inlining of `any @[]` vs `elem @[]`
by ÉRDI Gergő 12 Mar '21

12 Mar '21

Hi, The inlining behaviour of `any @[]` and `elem @[]` differs in a way that I am not sure is intentional, and it is affecting Clash (see https://github.com/clash-lang/clash-compiler/issues/1691) I would think that if it is a good idea to inline `any` then inlining `elem` would be just as good an idea, or vice versa. However, `any` is defined polymorphically over `Foldable`, via `foldMap` using `foldr`, with all steps between (and `foldr @[]`!) marked as `INLINE`. The result is that if you use `any (x ==) [1, 5, 7]` you get the following beautiful Core: ``` topEntity = \ (x_agAF :: Int) -> case x_agAF of { GHC.Types.I# y_ahao -> case y_ahao of { __DEFAULT -> GHC.Types.False; 1# -> GHC.Types.True; 5# -> GHC.Types.True; 7# -> GHC.Types.True } } ``` As the kids these days would say: *chef's kiss*. `elem`, on the other hand, is a typeclass method of `Foldable`, with a default implementation in terms of `any`, but overridden for lists with the following implementation: ``` GHC.List.elem :: (Eq a) => a -> [a] -> Bool GHC.List.elem _ [] = False GHC.List.elem x (y:ys) = x==y || GHC.List.elem x ys {-# NOINLINE [1] elem #-} {-# RULES "elem/build" forall x (g :: forall b . Eq a => (a -> b -> b) -> b -> b) . elem x (build g) = g (\ y r -> (x == y) || r) False #-} ``` This is marked as non-inlineable until phase 1 (so that `elem/build` has a chance of firing), but it seems that when build fusion doesn't apply (since `[1, 5, 7]` is, of course, not built via `build`), no inlining happens AT ALL, even in later phases, so we end up with this: ``` topEntity = \ (x_agAF :: Int) -> GHC.List.elem @ Int GHC.Classes.$fEqInt x_agAF (GHC.Types.: @ Int (GHC.Types.I# 1#) (GHC.Types.: @ Int (GHC.Types.I# 5#) (GHC.Types.: @ Int (GHC.Types.I# 7#) (GHC.Types.[] @ Int)))) ``` So not only does it trip up Clash, it would also result in less efficient code in software when using "normal" GHC. Is this all intentional? Wouldn't it make more sense to mark `GHC.List.elem` as `INLINE [1]` instead of `NOINLINE [1]`, so that any calls remaining after build fusion would be inlined? Thanks, Gergo

2 6

Re: WSL2
by Tom Ellis 11 Mar '21

11 Mar '21

SPJ Wrote: > I've just installed WSL2 and built GHC. I get this (single) > validation failure in libraries/unix/tests/getGroupEntryForName. It > seems to be just an error message wibble, but I can't push a change > to master because that'll affect everyone else. Interesting, I've only ever built GHC on WSL and WSL2. I've seen this error message on WSL2 during every test run, I think. I didn't realise that it never occurred on other platforms, let alone that it was WSL2 specific! Tom

4 11

What type of performance regression testing does GHC go through?
by Tom Ellis 11 Mar '21

11 Mar '21

A user posted the following to the ghc-proposals repository. Both JB and RAE suggested ghc-devs as a more appropriate forum. Since I have no idea whether the user has even ever used a mailing list before I thought I would lower the activation energy by posting their message for them. https://github.com/ghc-proposals/ghc-proposals/issues/410 > Hi, > > Does the GHC release or development process include regression > testing for performance? > > Is this the place to discuss ideas for implementing such a thing and > to eventually craft a proposal? > > I believe the performance impact of changes to GHC needs to be > verified/validated before release. I also believe this would be > feasible if we tracked metrics on building a wide variety of > real-world packages. Using real-world packages is one of the best > ways to see the actual impact users will experience. It's also a > great way to broaden the scope of tests, particularly with the > combination of language pragmas and enabled features within the > compiler.

2 1

WSL2
by Simon Peyton Jones 10 Mar '21

10 Mar '21

Friends I've just installed WSL2 and built GHC. I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can't push a change to master because that'll affect everyone else. Any ideas? Simon =====> 1 of 1 [0, 0, 0] ]0;getGroupEntryForName(normal) 1 of 1 [0, 0, 0]Actual stderr output differs from expected: --- getGroupEntryForName.run/getGroupEntryForName.stderr.normalised 2021-03-09 22:36:01.300421100 +0000 +++ getGroupEntryForName.run/getGroupEntryForName.run.stderr.normalised 2021-03-09 22:36:01.300421100 +0000 @@ -1 +1 @@ -getGroupEntryForName: getGroupEntryForName: does not exist (no such group) +getGroupEntryForName: getGroupEntryForName: does not exist (No such process) *** unexpected failure for getGroupEntryForName(normal)

2 2

Running ghc-debug on ghc
by Matthew Pickering 09 Mar '21

09 Mar '21

Hi, I now have some simple instructions for running ghc-debug on GHC. 1. Cherry-pick 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4 commit 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4 (HEAD -> wip/ghc-with-debug) Author: Matthew Pickering <matthewtpickering(a)gmail.com> Date: Fri Jan 8 11:26:17 2021 +0000 Add support for ghc-debug to ghc executable 2. Build GHC * Add the following to _build/hadrian.settings ``` stage1.*.ghc.hs.opts += -finfo-table-map -fdistinct-constructor-tables ``` * Build GHC as normal ``` ./hadrian/build -j8 ``` * The result is a ghc-debug enabled compiler # Building a debugger * Use the compiler you just built to build ghc-debug ``` cd ghc-debug cabal update cabal new-build debugger -w ../_build/stage1/bin/ghc ``` # Running the debugger Modify `test/Test.hs` to implement the debugging thing you want to do. Perhaps start with `p30`, which is a program to generate a profile. * Start the process you want to debug ``` GHC_DEBUG_SOCKET=/tmp/ghc-debug build-cabal ``` * Start the debugger ``` cabal new-run debugger -w ... ``` * Open a ticket about the memory issue you find. There is the start of some more documentation here - http://ghc.gitlab.haskell.org/ghc-debug/docs.html These instructions are also in the instructions.md file in the commit. Cheers, Matt

2 1

What changed between GHC 8.8 and 8.10 that could cause this?
by ÉRDI Gergő 09 Mar '21

09 Mar '21

Hi, I'm trying to figure out a Clash problem and managed to track it down to a GHC upgrade; specifically, a given Clash version, when based on GHC 8.8, has no problem synthesizing one module after another from one process; but the same Clash version with GHC 8.10 fails with link-time errors on the second compilation. The details are at https://github.com/clash-lang/clash-compiler/issues/1686 but for now I'm just hoping that some lightbulb will go off for someone if some handling of internal state has changed in GHC that could mean that the symbol tables of loaded modules could persist between GHC invocations from the same process. So, does this ring a bell for anyone? Thanks, Gergo

5 8

Requesting help with unregisterized backend failure of !4717
by John Ericson 09 Mar '21

09 Mar '21

Hi everyone, https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717 fails some numerical boundary checking tests with the unregisterized backend. In particular, `minBound / (-1)` and `pred minBound` are *not* diverging as expected. This stumped me a few days ago, and no new ideas have struct me since. I would very much appreciate some help. This does seem like something that is very likely to be backend-dependent, as different instructions/arches handle such edge cases in different ways. What makes this so peculiar, however, is that the boundary condition checking/branching is done *in regular Haskell*. I'm thus quite baffled as to what could be going wrong. If anyone wants to dive in, see my last comment https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_329840, which has a minimization to declutter the code without doing enough constant folding that the problem is avoided entirely. (I went with a compilation unit trick, but in hindsight NOINLINE should also work and be simpler.) Finally, let my provide some context for why I am hoping to get this merged soon. To be clear, !4492 was the main MR relating to the numerics primops critical to get in for 9.2 and it thankfully already landed. But landing this MR too would be nice: It shrinks the intermediate representations of numerical code probably smaller than it was originally, whereas now it is perhaps larger than it was before due to more size<->native conversions. Also, I think this MR will help get !3658 over the finish line, which, while again not as critical for 9.2 as !4492 was, would be awfully nice to do to fully realize the new simplicity of the plan set forth in https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics. Thanks, John N.B. I just rebased and repushed the MR, so CI might be still running or failing due to something else, but based on local testing this is still the an issue. https://gitlab.haskell.org/ghc/ghc/-/pipelines/31002 is an earlier pipeline run that one can look at until CI finishes again.

2 2

Pointer-or-Int 63-bit representations for Integer
by Chris Done 08 Mar '21

08 Mar '21

Hi all, In OCaml's implementation, they use a well known 63-bit representation of ints to distinguish whether a given machine word is either a pointer or to be interpreted as an integer. I was wondering whether anyone had considered the performance benefits of doing this for the venerable Integer type in Haskell? I.e. if the Int fits in 63-bits, just shift it and do regular arithmetic. If the result ever exceeds 63-bits, allocate a GMP/integer-simple integer and return a pointer to it. This way, for most applications--in my experience--integers don't really ever exceed 64-bit, so you would (possibly) pay a smaller cost than the pointer chasing involved in bignum arithmetic. Assumption: it's cheaper to do more CPU instructions than to allocate or wait for mainline memory. This would need assistance from the GC to be able to recognize said bit flag. As I understand the current implementation of integer-gimp, they also try to use an Int64 where possible using a constructor (https://hackage.haskell.org/package/integer-gmp-1.0.3.0/docs/src/GHC.Intege…) but I believe that the compiled code will still pointer chase through the constructor. Simple addition or subtraction, for example, is 24 times slower in Integer than in Int for 1000000 iterations: https://github.com/haskell-perf/numbers#addition An unboxed sum might be an improvement? e.g. (# Int# | ByteArray# #) -- would this "kind of" approximate the approach described? I don't have a good intuition of what the memory layout would be like. Just pondering. Cheers, Chris

4 4

Newcomer looking for mentorship on a HPC / Coverage related issue
by Javran Cheng 03 Mar '21

03 Mar '21

Hi all, I'm a newcomer (not entirely new as I did have some contribution few years back but the workflow seems to have changed a lot) and is working on https://gitlab.haskell.org/ghc/ghc/-/issues/15932. I'm looking for some (informal) mentorship on that issue - I think I know what the problem is <https://gitlab.haskell.org/ghc/ghc/-/issues/15932#note_283252>, but I need someone with more experience to help developing a concrete plan before working on a fix, as this might involve two parts in GHC codebase: HPC source code and GHC/HsToCore/Coverage. I tried to ask for comments and other related bits on IRC few months back but that doesn't attract much attention. Now that I'm in the mood of hacking GHC again, I figure probably finding a mentorship might work better. Thanks! Javran

2 1

Plan for GHC 9.2
by Ben Gamari 02 Mar '21

02 Mar '21

tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss, especially if you have something you would like merged for 9.2.1. Hello all, With GHC 9.0.1 at long-last out the door, it is time that we start turning attention to GHC 9.2. I would like to avoid making the mistake made in the 9.0 series in starting the fork in a state that required a significant amount of backporting to be releaseable. Consequently, I want to make sure that we have a fork schedule that is realistic given the things that need to be merged for 9.2. These include: * Update haddock submodule in `master` (Ben) * Bumping bytestring to 0.11 (#19091, Ben) * Finishing the rework of sized integer primops (#19026, John Ericson) * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry) * Merge BoxedRep (#17526, Ben) * ARM NCG backend and further stabilize Apple ARM support? (Moritz) * Some form of coercion zapping (Ben, Simon, Richard) * Tag inference analysis and tag check elision (Andreas) If you see something that you would like to see in 9.2.1 please do holler. Otherwise, if you see your name in this list it would be great if you could let me know when you think your project may be in a mergeable state. Ideally we would strive for a schedule like the following: 4 February 2021: We are here ~4 weeks pass 3 March 2021: Release branch forked 1 week passes 10 March 2021: Alpha 1 released 3 weeks pass 31 March 2021: Alpha 2 released 2 weeks pass 14 April 2021: Alpha 3 released 2 weeks pass 28 April 2021: Alpha 4 released 1 week passes 5 May 2021: Beta 1 released 1 week passes 12 May 2021: Release candidate 1 released 2 weeks pass 26 May 2021: Final release This provides ample time for stabilization while avoiding deviation from the usual May release timeframe. However, this would require that we move aggressively to start getting the tree into shape since the fork would be less than four weeks away. I would appreciate contributors' thoughts on the viability of this timeline. Cheers, - Ben

6 7