- ghc-devs - Haskell.org

how to map CLabel to Label for procedure entry point?
by Norman Ramsey 22 Nov '21

22 Nov '21

I'm struggling to figure out how to get from a CLabel found in a CmmProc to a Label used to key the blocks in the control-flow graph (CmmGraph) for the CmmProc. The code generator needs such a function, so it must be around somewhere, but I have not yet found it. I've poked around the respective modules for CLabel and for Label, and also modules like CmmToAsm. Can anyone help me out? Norman

1 0

[Take 2] Unexpected duplicate join points in "Core" output?
by Viktor Dukhovni 20 Nov '21

20 Nov '21

[ Sorry wrong version of attachment in previous message. ] The below "Core" output from "ghc -O2" (9.2/8.10) for the attached program shows seemingly rendundant join points: join { exit :: State# RealWorld -> (# State# RealWorld, () #) exit (ipv :: State# RealWorld) = jump $s$j ipv } in join { exit1 :: State# RealWorld -> (# State# RealWorld, () #) exit1 (ipv :: State# RealWorld) = jump $s$j ipv } in that are identical in all but name. These correspond to fallthrough to the "otherwise" case in: ... | acc < q || (acc == q && d <= 5) -> loop (ptr `plusPtr` 1) (acc * 10 + d) | otherwise -> return Nothing but it seems that the generated X86_64 code (also below) ultimately consolidates these into a single target... Is that why it is harmless to leave these duplicated in the generated "Core"? [ Separately, in the generated machine code, it'd also be nice to avoid comparing the same "q" with the accumulator twice. A single load and compare should I think be enough, as I'd expect the status flags to persist across the jump the second test. This happens to not be performance critical in my case, because most calls should satisfy the first test, but generally I think that 3-way "a < b", "a == b", "a > b" branches ideally avoid comparing twice... ] ======== Associated Core output -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} main2 :: Addr# main2 = "12345678901234567890 junk"# -- RHS size: {terms: 129, types: 114, coercions: 0, joins: 6/8} main1 :: State# RealWorld -> (# State# RealWorld, () #) main1 = \ (eta :: State# RealWorld) -> let { end :: Addr# end = plusAddr# main2 25# } in join { $s$j :: State# RealWorld -> (# State# RealWorld, () #) $s$j _ = hPutStr2 stdout $fShowMaybe4 True eta } in join { exit :: State# RealWorld -> (# State# RealWorld, () #) exit (ipv :: State# RealWorld) = jump $s$j ipv } in join { exit1 :: State# RealWorld -> (# State# RealWorld, () #) exit1 (ipv :: State# RealWorld) = jump $s$j ipv } in join { exit2 :: Addr# -> Word# -> State# RealWorld -> (# State# RealWorld, () #) exit2 (ww :: Addr#) (ww1 :: Word#) (ipv :: State# RealWorld) = case eqAddr# ww main2 of { __DEFAULT -> hPutStr2 stdout (++ $fShowMaybe1 (case $w$cshowsPrec3 11# (integerFromWord# ww1) [] of { (# ww3, ww4 #) -> : ww3 ww4 })) True eta; 1# -> jump $s$j ipv } } in joinrec { $wloop :: Addr# -> Word# -> State# RealWorld -> (# State# RealWorld, () #) $wloop (ww :: Addr#) (ww1 :: Word#) (w :: State# RealWorld) = join { getDigit :: State# RealWorld -> (# State# RealWorld, () #) getDigit (eta1 :: State# RealWorld) = case eqAddr# ww end of { __DEFAULT -> case readWord8OffAddr# ww 0# eta1 of { (# ipv, ipv1 #) -> let { ipv2 :: Word# ipv2 = minusWord# (word8ToWord# ipv1) 48## } in case gtWord# ipv2 9## of { __DEFAULT -> case ltWord# ww1 1844674407370955161## of { __DEFAULT -> case ww1 of { __DEFAULT -> jump exit ipv; 1844674407370955161## -> case leWord# ipv2 5## of { __DEFAULT -> jump exit1 ipv; 1# -> jump $wloop (plusAddr# ww 1#) (plusWord# 18446744073709551610## ipv2) ipv } }; 1# -> jump $wloop (plusAddr# ww 1#) (plusWord# (timesWord# ww1 10##) ipv2) ipv }; 1# -> jump exit2 ww ww1 ipv } }; 1# -> jump exit2 ww ww1 eta1 } } in jump getDigit w; } in jump $wloop main2 0## realWorld# ======== Executable disassembly The jumps at "-1->" and "-2->" that correspond that "otherwise" have the same target. The duplicate "load+cmp" with "q" is at "-3->" and "-4->": 0000000000408de8 <Main_main1_info>: 408de8: 48 8d 45 e8 lea -0x18(%rbp),%rax 408dec: 4c 39 f8 cmp %r15,%rax 408def: 0f 82 c8 00 00 00 jb 408ebd <Main_main1_info+0xd5> 408df5: b8 79 dd 77 00 mov $0x77dd79,%eax 408dfa: 31 db xor %ebx,%ebx 408dfc: b9 60 dd 77 00 mov $0x77dd60,%ecx 408e01: 48 39 c1 cmp %rax,%rcx 408e04: 74 66 je 408e6c <Main_main1_info+0x84> 408e06: 0f b6 11 movzbl (%rcx),%edx 408e09: 48 83 c2 d0 add $0xffffffffffffffd0,%rdx 408e0d: 48 83 fa 09 cmp $0x9,%rdx 408e11: 77 59 ja 408e6c <Main_main1_info+0x84> -3-> 408e13: 48 be 99 99 99 99 99 mov $0x1999999999999999,%rsi 408e1a: 99 99 19 408e1d: 48 39 f3 cmp %rsi,%rbx 408e20: 73 0c jae 408e2e <Main_main1_info+0x46> 408e22: 48 6b db 0a imul $0xa,%rbx,%rbx 408e26: 48 01 d3 add %rdx,%rbx 408e29: 48 ff c1 inc %rcx 408e2c: eb d3 jmp 408e01 <Main_main1_info+0x19> -4-> 408e2e: 48 be 99 99 99 99 99 mov $0x1999999999999999,%rsi 408e35: 99 99 19 408e38: 48 39 f3 cmp %rsi,%rbx -1-> 408e3b: 75 49 jne 408e86 <Main_main1_info+0x9e> 408e3d: 48 83 fa 05 cmp $0x5,%rdx -2-> 408e41: 77 43 ja 408e86 <Main_main1_info+0x9e> 408e43: 48 8d 5a fa lea -0x6(%rdx),%rbx 408e47: 48 ff c1 inc %rcx 408e4a: eb b5 jmp 408e01 <Main_main1_info+0x19> 408e4c: 0f 1f 40 00 nopl 0x0(%rax) 408e50: c2 00 00 retq $0x0 -- Viktor.

2 4

Re: How to build Haddock documentation quickly?
by Andrey Mokhov 20 Nov '21

20 Nov '21

Hi Norman, > I'm more than willing to dive into Hadrian and figure out how it works. > I could even add a new target to build just what I'm interested in. > But I would need help. I've spent some time poking around the `doc` directory, and I've read > the Shake papers (and some of Andrei's work) but I've never used these tools myself. I would be delighted to help you (or anyone else!) navigate Hadrian source code. Please feel free to get in touch directly. (Alas, in the last couple of years I couldn't contribute to improving Hadrian but that's not for the lack of desire - just due to some life changes. Hopefully I can at least help by helping others!) Cheers, Andrey

1 0

How to build Haddock documentation quickly?
by Norman Ramsey 19 Nov '21

19 Nov '21

In service of #20528, I'm trying to clean up some Haddock documentation in the GHC sources. The only command I know is ./hadrian/build -j _build/docs/html/index.html It turns out that if I change Haddock comments in one file (GHC/Tc/Gen/Foreign.hs), rebuilding the HTML takes a minute and a quarter. That's a little long. (And I had one build take over four minutes, which is even longer.) What tricks can I use to speed up this process? Might there be a way to run Haddock directly until things are to my liking? Norman

2 2

DWARF support
by Richard Eisenberg 19 Nov '21

19 Nov '21

Hi devs, I was intrigued by Bodigrim's comment about HasCallStack in base (https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-9…) that there are other alternatives, such as DWARF. Over the years, I had tuned out every time I saw the word DWARF: it was (and is!) an unknown acronym and seems like a low-level detail. But Bodigrim's comment made me want to re-think this stance. I found Ben's series of blog posts on DWARF, starting with https://www.haskell.org/ghc/blog/20200403-dwarf-1.html. These are very helpful! In particular, they taught me that DWARF = platform-native debugging metadata. Is that translation accurate? If so, perhaps we should use both names: if I see that GHC x.y.z has DWARF support, I quickly scroll to the next bullet. If I see that GHC x.y.z has support for platform-native debugging metadata and is now compatible with e.g. gdb, I'm interested. Going further, I have a key question for my use case: is this support available on Mac? The first post in the series describes support for "Linux and several BSDs" and the last post says that "Windows PDB support" is future work. (Is "PDB" platform-native debugging metadata for Windows? I don't know.) But I don't see any mention of Mac. What's the status here? It would be very cool if this conversation ends with me making a video on how a few simple GHC flags can allow us to, say, get a stack trace on a pattern-match failure in a Haskell program. Thanks! Richard

8 13

[ANNOUNCE] GHC 9.2.1 now available
by Ben Gamari 18 Nov '21

18 Nov '21

Hi all, The GHC developers are very happy to at long last announce the availability of GHC 9.2.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1 GHC 9.2 brings a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merging of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [`-hi` profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Significant improvements in the bytecode interpreter, allowing more programs to be efficently run in GHCi and Template Haskell splices. * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Faster compilation and a smaller memory footprint * Introduction of Haddock documentation support in TemplateHaskell (#5467) Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket] if you see anything amiss. Happy testing, - Ben [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

6 8

Interpreter thread in ghc-8.10.6 in macOS
by Domínguez, Facundo 16 Nov '21

16 Nov '21

Dear devs, I found recently that ghc-8.10.6 and ghc-8.10.7 might be behaving differently than previous compilers when running Template Haskell code. When upgrading HaskellR to use a newer ghc I found that it would work fine with ghc-8.10.4, but not ghc-8.10.6 or ghc-8.10.7. HaskellR, and the R runtime in particular, is sensitive to local state in the threads that are used to execute the runtime. HaskellR is arranging to run the R runtime when running TemplateHaskell splices, and this stopped working in MacOS with ghc-8.10.6. The error I got is not new. It comes from R and we would get it in ghci if we try to use HaskellR without passing the command line flag -fno-ghci-sandbox. But this is the first time we get the error when using TemplateHaskell. Does anyone know if there have been changes to the threads in which the TH splices are run? And were there any changes specific to TH in MacOS? Thanks in advance, Facundo [1] https://github.com/tweag/HaskellR/pull/368#issuecomment-968864170

3 4

request for comments: foreign calls (#20693)
by Norman Ramsey 16 Nov '21

16 Nov '21

I'd like it to be easier to extend GHC with support for new species of foreign calls. Existing support makes it easy to *replace* GHC's implementation of foreign calls but not to *extend* it. Details in #20693 (https://gitlab.haskell.org/ghc/ghc/-/issues/20693) I'd welcome comments, especially from anyone involved with GHCJS. Norman

1 0

Defaulting design choices
by Simon Peyton Jones 15 Nov '21

15 Nov '21

Sam, Richard, Adam, Vlad, Ryan, and other people interested in GHC's type system. Following discussion with Richard, I have created a new ticket #20686 for Make the design of defaulting explicit<https://gitlab.haskell.org/ghc/ghc/-/issues/20686>. This should inform !6851 which is trying to finish up Concrete# constraints. Please have a look - we 'd love your views on The Choice. Richard especially, but everyone really: feel free to edit the Description to make it more clear/accurate. I propose to treat it as our master design document. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj(a)microsoft.com.)

1 0

Case split uncovered patterns in warnings or not?
by Sebastian Graf 10 Nov '21

10 Nov '21

Hi Devs, In https://gitlab.haskell.org/ghc/ghc/-/issues/20642 we saw that GHC >= 8.10 outputs pattern match warnings a little differently than it used to. Example from there: {-# OPTIONS_GHC -Wincomplete-uni-patterns #-}foo :: [a] -> [a]foo [] = []foo xs = ys where (_, ys@(_:_)) = splitAt 0 xsmain :: IO ()main = putStrLn $ foo $ "Hello, coverage checker!" Instead of saying ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns not matched: (_, []) We now say ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns] Pattern match(es) are non-exhaustive In a pattern binding: Patterns of type ‘([a], [a])’ not matched: ([], []) ((_:_), []) E.g., newer versions do (one) case split on pattern variables that haven't even been scrutinised by the pattern match. That amounts to quantitatively more pattern suggestions and for each variable a list of constructors that could be matched on. The motivation for the change is outlined in https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110, but I could easily be swayed not to do the case split. Which arguably is less surprising, as Andreas Abel points out. Considering the other examples from my post, which would you prefer? Cheers, Sebastian

5 7