- ghc-devs - Haskell.org

Restricted sums in BoxedRep
by David Feuer 14 Oct '20

14 Oct '20

Null pointers are widely known to be a lousy language feature in general, but there are certain situations where they're *really* useful for compact representation. For example, we define newtype TMVar a = TMVar (TVar (Maybe a)) We don't, however, actually use the fact that (Maybe a) is lifted. So we could represent this much more efficiently using something like newtype TMVar a = TMVar (TVar a) where Nothing is represented by a distinguished "null" pointer. While it's possible to implement this sort of thing in user code (with lots of fuss and care), it's not very nice at all. What I'd really like to be able to do is represent certain kinds of sums like this natively. Now that we're getting BoxedRep, I think we can probably make it happen. The trick is to add a special Levity constructor representing sums of particular shapes. Specifically, we can represent a type like this if it is a possibly-nested sum which, when flattened into a single sum, consists of some number of nullary tuples and at most one Lifted or Unlifted type. Then we can have (inline) primops to convert between the BoxedRep and the sum-of-sums representations. Anyone have thoughts on details for what the Levity constructor arguments might look like?

3 6

Seeking performance-minded reviewers on !2965
by Ryan Scott 12 Oct '20

12 Oct '20

!2965 [1] seeks to improve the performance of derived Generic(1) instances by heuristically annotating implementations of the from(1) and to(1) class methods with INLINE[1] pragmas. For the most part, this results in performance wins, as the generic intermediate representations of data types can be optimized away in more situations. However, I'm unclear on one aspect of the MR: it actually leads to a compile-time performance increase (specifically, in bytes allocated) in one test case: T12227: Test Metric value New value Change T12227(normal) ghc/alloc 518417756.0 526479616.0 +1.6% BAD The MR author provides an explanation for why this happens here [2]. However, as I am not really a GHC performance guru, it's difficult for me to accurately judge whether this difference is within acceptable limits or not. For those of you who care about compile-time performance, would you be willing to give !2965 a look over and judge whether the difference is acceptable? I think this is the last remaining hurdle to clear before we can land !2965, so your input would be greatly appreciated. Thanks! Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2965 [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2965#note_304501

1 0

Help making exception-related primops open-kinded
by David Feuer 02 Oct '20

02 Oct '20

I'm pretty sure raiseIO#, catch#, maskAsyncExceptions#, and so on can have open-kinded results. For example, we currently have catch# :: (State# RealWorld -> (# State# RealWorld, a #) ) -> (b -> State# RealWorld -> (# State# RealWorld, a #) ) -> State# RealWorld -> (# State# RealWorld, a #) but I think we *should* be able to have catch# :: (State# RealWorld -> (# State# RealWorld, o #) ) -> (b -> State# RealWorld -> (# State# RealWorld, o #) ) -> State# RealWorld -> (# State# RealWorld, o #) This should allow us to avoid boxing things just to be able to get them out of a `catch#` or `maskAsyncExceptions#` block. But when I tried just changing the types in primops.txt.pp, I got a type mismatch error that seems to suggest some sort of GHC build staging issue. How can I work around this? See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4192/diffs for my attempt.

1 0

How is GHC.Prim.unpackInt8X64# meant to be used?
by Ryan Scott 28 Sep '20

28 Sep '20

GHC imposes an upper bound of 62 on the size of tuples one can use [1]. Currently, this upper bound applies to both boxed and unboxed tuples alike. For example, if you try to create an unboxed tuple of arity 64, then GHC will throw an error: error: A 64-tuple is too large for GHC (max size is 62) Workaround: use nested tuples or define a data type | | f = (#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,#) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ However, I discovered recently that there are places where GHC *does* use unboxed tuples with arity greater than 62. For example, the GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size 64. I was confused for a while about how this was even possible, but I realized later than GHC only enforces the tuple size limit in expressions and patterns [3]. Simply having a type signature with a large unboxed tuple is fine in and of itself, and since unpackInt8X64# is implemented as a primop, no large unboxed tuples are ever used in the "body" of the function. (Indeed, primops don't have function bodies in the conventional sense.) Other functions in GHC.Prim that use unboxed tuples of arity 64 include unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6]. But this makes me wonder: how on earth is it even possible to *use* unpackInt8X64#? The only thing that comes to mind is to pattern-match on the unboxed tuple that it returns, but if you try to do that, you'll get a "64-tuple is too large for GHC" error like shown above. What's more, I can't find any test cases in the GHC test suite that show how unpackInt8X64# or its cousins are supposed to be used. What am I missing? The comments for these functions mention "Warning: this is only available on LLVM", so perhaps someone familiar with the LLVM backend knows what the answer is? For some context, this came up in !4097, where I am attempting to extend the "too large for GHC" error message to include types, in addition to expressions and patterns [7]. However, doing so causes Haddock to error when processing unpackInt8X64# et al. Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4… [2] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unp… [3] https://gitlab.haskell.org/ghc/ghc/-/issues/18723 [4] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unp… [5] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:pac… [6] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:pac… [7] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4097#note_301191

7 9

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