- ghc-devs - Haskell.org

Re: msys woes
by Shayne Fletcher 01 Nov '20

01 Nov '20

On Thu, Oct 8, 2020 at 1:18 PM Phyx <lonetiger(a)gmail.com> wrote: > From the looks of it the repo.msys2.org system doesn't have enough space > to restore all these old packages. > > So we'll have to handle it on our end. The easiest way to get your builds > working again is by applying a patch with the fix to the source tree. > > New problems in this space as of today. This time with ```bash stack --stack-yaml stack.yaml --resolver nightly-2020-01-08 exec -- pacman -S autoconf automake-wrapper make patch python tar mintty --noconfirm ``` which produces 404 errors ``` 2020-11-01T16:02:47.2564782Z :: Retrieving packages... 2020-11-01T16:02:49.0237771Z error: failed retrieving file 'diffutils-3.6-1-x86_64.pkg.tar.xz' from repo.msys2.org : The requested URL returned error: 404 2020-11-01T16:02:49.3752086Z error: failed retrieving file 'diffutils-3.6-1-x86_64.pkg.tar.xz' from downloads.sourceforge.net : The requested URL returned error: 404 2020-11-01T16:02:49.8476086Z error: failed retrieving file 'diffutils-3.6-1-x86_64.pkg.tar.xz' from www2.futureware.at : The requested URL returned error: 404 2020-11-01T16:02:49.8482030Z warning: failed to retrieve some files 2020-11-01T16:02:51.2288388Z error: failed retrieving file 'autoconf-2.69-3-any.pkg.tar.xz' from repo.msys2.org : The requested URL returned error: 404 2020-11-01T16:02:51.3674499Z error: failed retrieving file 'autoconf-2.69-3-any.pkg.tar.xz' from downloads.sourceforge.net : The requested URL returned error: 404 2020-11-01T16:02:51.4787091Z error: failed retrieving file 'autoconf-2.69-3-any.pkg.tar.xz' from www2.futureware.at : The requested URL returned error: 404 2020-11-01T16:02:51.4791763Z warning: failed to retrieve some files ... ``` I've raised https://github.com/msys2/MSYS2-packages/issues/2225 with msys2. -- Shayne Fletcher

1 0

GitLab down
by Ben Gamari 26 Oct '20

26 Oct '20

Hi all, GitLab will be down for a bit while I do a bit of maintenance. Cheers, - Ben

2 3

GHC's internal confusion about Ints and Words
by Moritz Angermann 22 Oct '20

22 Oct '20

Hi there! So there is a procedure calling convention that for reasons I did not fully understand, but seem to be historically grown, uses packed arguments for those that are spilled onto the stack. On top of that, CInt is 32bit, Word is 64bits. This provides the following spectacle: While we know in STG that the CInt is 32bits wide, when lowered into Cmm, it's represented as I64 in the arguments to the C function. Thus packing based on the format of the Cmm type would yield 8 bytes. And now, all further packed arguments have the wrong offset (by four). Specifically in GHC.Cmm.Utils we find: primRepCmmType :: Platform -> PrimRep -> CmmType primRepCmmType platform IntRep = bWord platform mkIntCLit :: Platform -> Int -> CmmLit mkIntCLit platform i = CmmInt (toInteger i) (wordWidth platform) The naive idea to just fix this and make them return cIntWidth instead, seemingly produces the correct Cmm expressions at a local level, but produces a broken compiler. A second approach could be to extend the Hints into providing sizes, and using those during the foreign call generation to pack spilled arguments. This however appears to be more of a patching up of some fundamental underlying issue, instead of rectifying it properly. Maybe I'll have to go down the Hint path, it does however break current Eq assumptions, as they are sized now, and what was equal before, is only equal now if they represent the same size. >From a cursory glance at the issues with naively fixing the width for Int, it seems that GHC internally assumes sizeof(Int) = sizeof(Word). Maybe there is a whole level of HsInt vs CInt discrimination missing? Cheers, Moritz

5 8

GitLab e-mails: down for everyone, or just me?
by Ryan Scott 22 Oct '20

22 Oct '20

Since yesterday, I haven't been receiving any e-mail notifications from GitLab. Are other people having this problem too, or is it a problem on my end? Ryan S.

2 1

Fwd: Restricted sums in BoxedRep
by David Feuer 15 Oct '20

15 Oct '20

Forwarded from Andrew Martin below. I think we want more than just Maybe (more than one null), but the nesting I described is certainly more convenience than necessity. ---------- Forwarded message --------- From: Andrew Martin <andrew.thaddeus(a)gmail.com> Date: Wed, Oct 14, 2020, 4:14 PM Subject: Re: Restricted sums in BoxedRep To: David Feuer <david.feuer(a)gmail.com> You'll have to forward this to the ghc-devs list to share it with others since I'm not currently subscribed to it, but I've had this same thought before. It is discussed at https://github.com/andrewthad/impure-containers/issues/12. Here's the relevant excerpt: > Relatedly, I was thinking the other day that after finishing implementing > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0203-p…, > I should really look at seeing if it's possible to add this > maybe-of-a-lifted value trick straight to GHC. I think that with: > > data RuntimpRep > = BoxedRep Levity > | MaybeBoxedRep Levity > | IntRep > | ... > > data BuiltinMaybe :: forall (v :: Levity). TYPE v -> TYPE ('MaybeBoxedRep v) > > This doesn't have the nesting issues because the kind system prevents > nesting. But anyway, back to the original question. I would recommend not > using Maybe.Unsafe and using unpacked-maybe instead. The latter is > definitely safe, and it only costs an extra machine word of space in each > data constructor it gets used in, and it doesn't introduce more > indirections. > On Tue, Oct 13, 2020 at 5:47 PM David Feuer <david.feuer(a)gmail.com> wrote: > 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? > -- -Andrew Thaddeus Martin

4 11

Perf test viewer
by Sylvain Henry 15 Oct '20

15 Oct '20

Hello everyone, Since testsuite performance results are stored into Git notes, they are more difficult to visualize. At least with values in .T files we could see the changes over time, but now increase/decrease are only indicated into commit messages (but not necessarily by how much). The only tool we have afaik is the perf_notes.py script [1] but it's not very interactive. So, long story short, I've started another one which is more interactive (in the browser). An instance is running on my server: http://hsyl20.fr:4222 It should be updated every 2 hours with newer metrics/commits from CI. Sources are here: https://github.com/hsyl20/had Any feedback/PR is welcome! Cheers, Sylvain [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-tests/performan…

2 1

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