- ghc-devs - Haskell.org

Native Code Generator for AArch64
by Moritz Angermann 27 Sep '20

27 Sep '20

Hi there! As some may know I've been working on a native code generation backend for aarch64[1]. When Ben initially wrote about The state of GHC on ARM[2], I was quite skeptical if a native code generator would really be what we should be doing. And the claim it would take a week or two, might have been underestimating the complexity a bit; but also the time needed to debug crashing programs. The idea of a NCG however intrigued me. I did work on an alternative llvm backend once, so I did know a bit about the code gen backend. I also knew a bit about aarch64 assembly from working on the rts linker for aarch64. So here we are today, with an aarch64 ncg for ghc[3], that has some basic optimizations included, but does not beat the llvm codegen yet in runtime performance. It is however substantially faster than the llvm codegen for compile time performance. I have performed nofib benchmarks for: - full llvm build vs full native build[4] - llvm nofib, with native libraries, vs full native build[5] to discriminate effects of compiling just the nofib programs vs. the impact the libraries have. I've only had time to take a cursory look over the generated assembly for the CSD test, and the llvm codegen seems to be able to produce quite different assembly, thus there seem to be some good optimizations llvm manages to exploit. I'll have to investigate this closer and probably look at the llvm IR we generate and the intermediate optimization steps llvm manages to apply to it, as the llvm assembly doesn't ressemble the ncg assembly much. I plan to look at aarch64/mach-o and performance over the coming weeks. I hope we can get this in for 9.2. Cheers, Moritz -- [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641 [2]: https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html [3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641 [4]: https://gist.github.com/9d93454b832b769b5bdb4e731a10c068 [5]: https://gist.github.com/acc4dab7836f1f509716ac398a94d949

3 2

Re: Quick Look has landed
by Alejandro Serrano Mena 25 Sep '20

25 Sep '20

Awesome news! Thanks so much, Simon, for all the programming effort you've put into this :) Alejandro El jue., 24 sept. 2020 a las 22:04, Dimitrios Vytiniotis (< dimitriv(a)gmail.com>) escribió: > Wow this is great news!!! We finally landed something acceptable after 15 > years.... Thanks so much for all the hard work on the implementation side > Alejandro and Simon. > > On Thu, 24 Sep 2020, 21:21 Simon Peyton Jones, <simonpj(a)microsoft.com> > wrote: > >> Dimitrios, Jurriaan, Alejandro >> >> I’m happy to tell you that Quick Look has landed on GHC’s master branch. >> >> It’ll be in GHC 9.2, but is usable already by building HEAD. Good work! >> >> The implementation is very faithful to the paper, which was an invaluable >> guide. >> >> Simon >> >

1 0

Quick Look has landed
by Simon Peyton Jones 24 Sep '20

24 Sep '20

Dimitrios, Jurriaan, Alejandro I'm happy to tell you that Quick Look has landed on GHC's master branch. It'll be in GHC 9.2, but is usable already by building HEAD. Good work! The implementation is very faithful to the paper, which was an invaluable guide. Simon

1 0

GHC 8.10.2 build error: missing .cfi_startproc
by Björn Gohla 22 Sep '20

22 Sep '20

Hello, I'm trying to build ghc-8.10.2 on OpenBSD 6.7, the build finally fails with an error message from the assembler: ===--- building phase 0 gmake --no-print-directory -f ghc.mk phase=0 phase_0_builds gmake[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 gmake --no-print-directory -f ghc.mk phase=1 phase_1_builds gmake[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase gmake --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-w -static -O0 -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgCRun.c -o rts/dist/build/StgCRun.o rts/StgCRun.c: Assembler messages: rts/StgCRun.c:382:0: error: Error: CFI instruction used without previous .cfi_startproc | 382 | "movq %%rbx,0(%%rax)\n\t" | ^ rts/StgCRun.c:383:0: error: Error: CFI instruction used without previous .cfi_startproc | 383 | "movq %%rbp,8(%%rax)\n\t" | ^ rts/StgCRun.c:384:0: error: Error: CFI instruction used without previous .cfi_startproc | 384 | "movq %%r12,16(%%rax)\n\t" | ^ rts/StgCRun.c:385:0: error: Error: CFI instruction used without previous .cfi_startproc | 385 | "movq %%r13,24(%%rax)\n\t" | ^ rts/StgCRun.c:386:0: error: Error: CFI instruction used without previous .cfi_startproc | 386 | "movq %%r14,32(%%rax)\n\t" | ^ rts/StgCRun.c:387:0: error: Error: CFI instruction used without previous .cfi_startproc | 387 | "movq %%r15,40(%%rax)\n\t" | ^ rts/StgCRun.c:388:0: error: Error: CFI instruction used without previous .cfi_startproc | 388 | #if defined(mingw32_HOST_OS) | ^ rts/StgCRun.c:389:0: error: Error: CFI instruction used without previous .cfi_startproc | 389 | /* | ^ rts/StgCRun.c:390:0: error: Error: CFI instruction used without previous .cfi_startproc | 390 | * Additional callee saved registers on Win64. This must match | ^ `egcc' failed in phase `Assembler'. (Exit code: 1) gmake[1]: *** [rts/ghc.mk:322: rts/dist/build/StgCRun.o] Error 1 gmake: *** [Makefile:128: all] Error 2 Looking in the source file rts/StgCRun.c and reading the GNU assembler manual concerning CFI directives, it seems to me that in the function StgRunIsImplementedInAssembler starting on line 368 the assembler block should perhaps have started with .cfi_startproc and ended with .cfi_endproc . Although I suspect it's perhaps a question of telling GCC not to expect those directives. I'm using gcc-8.3.0 and ghc-8.6.4 to compile. I would be grateful for any insight anyone might have to offer. -- Kindly, Björn Gohla

1 0

Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...
by Sebastian Graf 18 Sep '20

18 Sep '20

Hey Sylvain, In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971 I had to fight once more with the transitive dependency set of the parser, the minimality of which is crucial for ghc-lib-parser <https://hackage.haskell.org/package/ghc-lib-parser> and tested by the CountParserDeps test. I discovered that I need to make (parts of) `DsM` abstract, because it is transitively imported from the Parser for example through Parser.y -> Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}. Since you are our mastermind behind the "Tame DynFlags" initiative, I'd like to hear your opinion on where progress can be/is made on that front. I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961 and https://gitlab.haskell.org/ghc/ghc/-/issues/11301 which ask a related, but different question: They want a DynFlags-free interface, but I even want a DynFlags-free *module*. Would you say it's reasonable to abstract the definition of `PState` over the `DynFlags` type? I think it's only used for pretty-printing messages, which is one of your specialties (the treatment of DynFlags in there, at least). Anyway, can you think of or perhaps point me to an existing road map on that issue? Thank you! Sebastian

8 16

Weird "missing hi file" problem with a serializable Core patch
by Cheng Shao 17 Sep '20

17 Sep '20

Hi all, Following a short chat in #ghc last week, I did a first attempt of reusing existing Iface logic to implement serialization for codegen-related Core. The implementation is included in the attached patch (~100 loc). As a quick and dirty validation of whether it works, I also modified the codegen pipeline logic to do a roundtrip: after CorePrep, the Core bits are converted to Iface, then we immediately convert it back and use it for later compiling. With the patch applied, stage-1 GHC would produce a "missing hi file" error like: : Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi _build/stage1/libraries/ghc-prim/build/GHC/Types.hi: openBinaryFile: does not exist (No such file or directory) The error surprises me, since by the time we perform the Core-to-Core roundtrip, the .hi file should already have been written to disk. Is there anything obviously wrong with the implementation? I'd appreciate any pointers or further questions, thanks a lot! Best regards, Cheng

4 5

WebUI for GHC/Haskell tooling (eventlog)
by Csaba Hruska 14 Sep '20

14 Sep '20

Hello, I've written a blog post <https://www.patreon.com/posts/41065262> about my WebUI based eventlog related tool. It is also related to eventlog2html and ghc-debug. I'm interested in your opinion and ideas related to ghc debug/profiling tooling. If you have time please read the post and it would be great to hear some positive or negative feedback from you. It would be great to discuss this topic with you. Thanks, Csaba

4 3

Simplifier vs. rules problem
by michael.sperber＠active-group.de 11 Sep '20

11 Sep '20

I've been trying to make Conal's ConCat plugin work for polymorphic code, and am running into some problems with the ghc doing that, and I'd very much appreciate help with that. Background: I'm trying to get -dcore-lint to flag when my actual problem happens (has to do with dictionary construction, but it fails earlier with another problem, which I think comes from the simplifier. tl;dr: This transformation seems to me problematic: https://ghc-compiler-notes.readthedocs.io/en/latest/notes/compiler/simplCor… The docs for the transformation say that it makes this replacement: case a +# b of r -> …r… into let r = a +# b in …r… But this creates a let binding with an unlifted binder, which the linter does not like: <no location info>: warning: [RHS of ... :: Int#] The type of this binder is unlifted: ... Binder's type: Int# Arguably, this rule might expect the let to be inlined, but we're seeing that the let stands, and the linter complains. My immediate concern is getting around this problem somehow so I can run the linter on later output of the simplifier. Is there any way to do this? I.e. don't stop when the linter complains, somehow massage the rules to work better - see below. Any help would be much appreciated! (I'm using ghc 8.8.3.) More details: The ConCat code has this rule: "rebox2" [~0] (+#) = \ u# v# -> unboxI (addC (boxI u#, boxI v#)) It fires like this: Rule fired Rule: rebox_2 Module: (ConCat.Rebox) Before: GHC.Prim.+# ValArg 10# ValArg 1# After: (\ (u#_aM4G :: GHC.Prim.Int#) (v#_aM4H :: GHC.Prim.Int#) -> ConCat.Rebox.unboxI (ConCat.AltCat.addC @ (->) @ GHC.Types.Int (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt) (ConCat.Rebox.boxI u#_aM4G, ConCat.Rebox.boxI v#_aM4H))) 10# 1# Cont: Stop[BoringCtxt] GHC.Prim.Int# ... and comes out of the simplifier like this: let { n1_sM4V :: GHC.Prim.Int# [LclId, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 0}] n1_sM4V = case ConCat.AltCat.addC @ (->) @ GHC.Types.Int (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt) (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#) of { GHC.Types.I# i#_aM4S -> i#_aM4S } } in GHC.Types.I# (case ConCat.AltCat.addC @ (->) @ GHC.Types.Int (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt) (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#) of { GHC.Types.I# i#_aM4S -> i#_aM4S }) } in ... Ironically, you can see that the simplifier already *has* inlined, just not elided the (now dead) let binding yet, before the linter gets to it. I've also attached a shorter source file with the relevant rules that triggers the linter, albeit with a different message. Richard Eisenberg, Gabor Greif, and Conal helped me get to this point. Many thanks to them! -- Regards, Mike {-# LANGUAGE MagicHash #-} {-# OPTIONS_GHC -frewrite-rules #-} {-# OPTIONS_GHC -ddump-rule-rewrites #-} {-# OPTIONS_GHC -ddump-rules #-} {-# OPTIONS_GHC -dcore-lint #-} {-# OPTIONS_GHC -ddump-simpl #-} module ConCatRules where import GHC.Prim import GHC.Int boxI :: Int# -> Int boxI = I# {-# INLINE [0] boxI #-} unboxI :: Int -> Int# unboxI (I# i#) = i# -- {-# INLINE [0] unboxI #-} plus :: Int -> Int -> Int plus x y = undefined {-# NOINLINE plus #-} {-# RULES "reboxa" forall u# v# . (+#) u# v# = unboxI (plus (boxI u#) (boxI v#)) "reboxb" forall u# . (+#) u# = \v# -> unboxI (plus (boxI u#) (boxI v#)) "reboxc" (+#) = \ u# v# -> unboxI (plus (boxI u#) (boxI v#)) #-} foo = I# (10# +# 1#)

2 1

!RE: Implicit reboxing of unboxed tuple in let-patterns
by Simon Peyton Jones 10 Sep '20

10 Sep '20

I’m a bit late to this debate, but here are a few thoughts. 1. “Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the binding is strict.” Not only is this rule simple and consistent, it is also necessary: we cannot bind a variable of unlifted type to a thunk. So any new rule must include this, and maybe add something extra, complicating the language. 1. All lazy pattern bindings go via an intermediate tuple. If you write (Just x, [y]) = e then you get t = case e of (Just x, [y]) -> (x,y) x = fst t y = snd t The pattern can be complex and we don’t want to unpack it many times. Moreover, the semantics says that it must be fully matched, so even if you just want ‘x’, you must check that the second component of the pair is indeed a singleton list. So the “going via a tuple” part is nothing special about unboxed tuples – it simply holds for all lazy pattern bindings. 1. I don’t understand the details of Iavor’s proposal to add that “unlifted patterns are strict”, in addition to (1). Do you mean “any sub-pattern of the LHS has an unlifted type”? So Just (# a,b #) = e would be strict. And even MkT _ = e would be strict if data T = MkT (# Int,Int #) 1. Anything we do *must* scale to when we have user-defined unlifted data types (a current GHC Proposal) TL;DR. At the moment a change does not look attractive to me. I could live with a warning for *outermost* unboxed tuples (or in general a constructor of an unlifted data type), suggesting to add a “!” or a “~” to make the intent clear. Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Richard Eisenberg Sent: 02 September 2020 14:47 To: Spiwack, Arnaud <arnaud.spiwack(a)tweag.io> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: Re: Implicit reboxing of unboxed tuple in let-patterns On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack(a)tweag.io<mailto:arnaud.spiwack@tweag.io>> wrote: Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know what the semantics of these ought to be. It does look like an interesting can of worms. How do they currently desugar? Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the pattern is an unlifter-var pattern and is strict. The pattern must be banged, unless the bound variable is not nested. This rule is consistent across all features. This thread is suggesting to add a special case -- one that seems to match intuition, but it's still a special case. And my question is: should the special case be for unboxed tuples? or should the special case be for any pattern whose overall type is unlifted? Richard

5 8

non-threaded rts and CollectGarbage
by Moritz Angermann 09 Sep '20

09 Sep '20

Hi there! in the non-threaded rts we use itimer to do light weight scheduling of threads via SIGALRM signals. I'm seeing quite a bit of heap corruption on aarch64, and it appears that I also see a lot of signal handling in the GC, for example during evacuate. Is there a fundamental reason why we can't just disable the timer during GC? Cheers, Moritz

1 0