July 2018 - ghc-devs - Haskell.org

Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?
by Abhiroop Sarkar 16 Jul '18

16 Jul '18

Hello all, I am currently working on adding support for SIMD operations to the native code generator. One of the roadblocks I faced recently was the definition of the `globalRegType` function in "compiler/cmm/CmmExpr.hs". The `globalRegType` function maps the STG registers to the respective `CmmType` datatype. For Xmm, Ymm, Zmm registers the function defines globalRegType like this: https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmExpr.hs#L585-L587 Consider the case for an Xmm register, the above definition limits an Xmm register to hold only vectors of size 4. However we can store 2 64-bit Doubles or 16 Int8s or 8 Int16s and so on The function `globalRegType` is internally called by the function `cmmRegType` ( https://github.com/ghc/ghc/blob/838b69032566ce6ab3918d70e8d5e098d0bcee02/co…) which is itself used in a number of places in the x86 code generator. In fact depending on the result of the `cmmRegType` function is another important function `cmmTypeFormat` defined in Format.hs whose result is used to print the actual assembly instruction. I have extended all the other Format types to include VectorFormats, however this definition of the `globalRegType` seems incorrect to me. Looking at the signature of the function itself: `globalRegType :: DynFlags -> GlobalReg -> CmmType` its actually difficult to predict the CmmType by just looking at the GlobalReg in case of Xmm, Ymm, Zmm. So thats why my original question how do I go about solving this. Should I modify the GlobalReg type to contain more information like Width and Length(for Xmm, Ymm, Zmm) or do I somehow pass the length and width information to the globalRegType function? Thanks Abhiroop Sakar

3 8

RE: [commit: ghc] master: Remove ASSERTion about increasing TcLevels (a754a42)
by Simon Peyton Jones 15 Jul '18

15 Jul '18

Richard, weren't you going to open a ticket to track this? It ought to hold! Simon | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 15 July 2018 02:28 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Remove ASSERTion about increasing TcLevels | (a754a42) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2Fa754a420b53cd2210ef60dcd695bf3334af2e40 | 0%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9b543b1c10fd4fcae84c | 08d5e9f2325b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636672148791196 | 487&sdata=o8HfV%2FQqEfk0wKuW1XStZXzkn%2FkyDbw8DsfBIpTnzpw%3D&rese | rved=0 | | >--------------------------------------------------------------- | | commit a754a420b53cd2210ef60dcd695bf3334af2e400 | Author: Richard Eisenberg <rae(a)cs.brynmawr.edu> | Date: Thu Jul 12 16:10:34 2018 -0400 | | Remove ASSERTion about increasing TcLevels | | This removes an ASSERTion that TcLevels should increase by | exactly one in every implication. While this is a sensible | goal, it's not true today, and we should not be crippling | DEBUG for everyone while debugging this. | | The ASSERT was added in 261dd83cacec71edd551e9c581d05285c9ea3226 | | | >--------------------------------------------------------------- | | a754a420b53cd2210ef60dcd695bf3334af2e400 | compiler/typecheck/TcSimplify.hs | 8 +++++++- | 1 file changed, 7 insertions(+), 1 deletion(-) | | diff --git a/compiler/typecheck/TcSimplify.hs | b/compiler/typecheck/TcSimplify.hs | index 13a3f73..c57ef56 100644 | --- a/compiler/typecheck/TcSimplify.hs | +++ b/compiler/typecheck/TcSimplify.hs | @@ -1495,7 +1495,8 @@ solveImplication imp@(Implic { ic_tclvl = tclvl | = do { inerts <- getTcSInerts | ; traceTcS "solveImplication {" (ppr imp $$ text "Inerts" <+> ppr | inerts) | | - ; when debugIsOn check_tc_level | + -- commented out; see `where` clause below | + -- ; when debugIsOn check_tc_level | | -- Solve the nested constraints | ; (no_given_eqs, given_insols, residual_wanted) | @@ -1544,10 +1545,15 @@ solveImplication imp@(Implic { ic_tclvl = tclvl | -- TcLevels must be strictly increasing (see (ImplicInv) in | -- Note [TcLevel and untouchable type variables] in TcType), | -- and in fact I thinkthey should always increase one level at a | time. | + | + -- Though sensible, this check causes lots of testsuite failures. It | is | + -- remaining commented out for now. | + {- | check_tc_level = do { cur_lvl <- TcS.getTcLevel | ; MASSERT2( tclvl == pushTcLevel cur_lvl | , text "Cur lvl =" <+> ppr cur_lvl $$ | text "Imp lvl =" <+> ppr tclvl ) } | + -} | | ---------------------- | setImplicationStatus :: Implication -> TcS (Maybe Implication) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9b543b1c10fd4fcae84c | 08d5e9f2325b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636672148791196 | 487&sdata=V1pVxb4Crgjv04p9ZCGx7BDis0eXSV2fV9MDOPZXZEA%3D&reserved | =0

1 0

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 14 Jul '18

14 Jul '18

Dear Haskell community, the GHC Steering committee is seeking nominations for a new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 23th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

RE:: Can a TC plugin create new skolem vars when simplifying Givens?
by Simon Peyton Jones 11 Jul '18

11 Jul '18

Nick writes Here's a small indicative example. In the "simplify Givens" step, the plugin receives [G] (p `Union` Singleton A) ~ (q `Union` Singleton B) and I would ideally simplify that to [G] p ~ (x `Union` Singleton B) [G] q ~ (x `Union` Singleton A) If we think of Union as a type-level function (which it is?), then the step you outline above is similar to what happens during “flattening” of the Givens. We get this: [G] fsk1 ~ p `Union` Singleton B (CFunEqCan) [G] fsk2 ~ q `Union` Singleton A (CFunEqCan) [G] fsk1 ~ fsk2 (CTyEqCan) * The newly generated skolems are called “flatten-skolems” or fsks for short. * The new skolems are kept in the `inert_fsks` field of the `InertSet`. * A new one is created by `TcSMonad.newFlattenSkolem` * All fsks are eliminated by TsSMonad.unflattenGivens Returning to your point, you are exploiting a property of sets that allows you to say that if p U X = q U Y Then suppose r = p • q then p = r U Y, q = r U X And now we can eliminate all uses of p, q in favour of r. But if you do this in a type system, we have a problem: where is ‘r’ bound? E.g. if you have f :: forall p q. (p `Union` A) ~ (q `Union` B) => blah Then p, q are bound by the forall, but r is not. To put it another way, what well-typed Core program would you like to generate? You could do this: [G] fsk1 ~ p `Union` Singleton B (CFunEqCan) [G] fsk2 ~ q `Union` Singleton A (CFunEqCan) [G] fsk3 ~ p `Intersect` q (CFunEqCan) [G] fsk4 ~ fsk3 `Union` Singleton B (CFunEqCan) [G] fsk5 ~ fsk3 `Union` Singleton A (CFunEqCan) [G] fsk1 ~ fsk2 (CTyEqCan) [G] p ~ fks4 (CTyEqCan) [G] q ~ fsk5 (CTyEqCan) The ‘r’ is just fsk3. It’ll be eliminated by unflattenGivens, so there is no problem with scoping. I have no idea whether that’ll help you prove the things you want to prove! Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org<mailto:ghc-devs-bounces@haskell.org>> On Behalf Of Nicolas Frisby Sent: 24 June 2018 19:01 To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Can a TC plugin create new skolem vars when simplifying Givens? I'm still spending the occasional weekend working on a type checker plugin for row types (actually "set" types at first, but I haven't thought of a less ambiguous term for that). One point of complexity in the plugin has to do with creating fresh variables when simplifying Givens. Some constraints are traditionally simplified by introducing a fresh variable. For Wanted constraints, that's easy (newFlexiTyVar). For Givens, though, I haven't figured out how to do it. This email is just to ask these two questions: 1) Is there a function to add a new skolem variable when simplifying Givens? 2) Assuming not, is there a strong reason for there to never be such a function? Here's a small indicative example. In the "simplify Givens" step, the plugin receives [G] (p `Union` Singleton A) ~ (q `Union` Singleton B) and I would ideally simplify that to [G] p ~ (x `Union` Singleton B) [G] q ~ (x `Union` Singleton A) for some fresh skolem variable x. But I don't see how to properly create a fresh skolem variable in the Givens. If these were Wanteds, I would just use newFlexiTyVar. I think this is analogous to a hypothetical type checker plugin that eta expands tuples. If we were to simplify [G] ... (x :: (k1,k2)) ... to [G] ... '(x1 :: k1,x2 :: k2) ... we'd have to generate x1 and x2 somehow. The only method I'm aware of for that is to use Fst x and Snd x instead (ie type families). That might be acceptable for the tuple expansion example, but I'm very reticent to use something like that for the set types plugin. I have a plan to get by without creating these variables when simplifying Givens, but it's not simple. I'd be delighted if it were possible to create them. Hence my two questions listed above. Thank you for your time. -Nick

1 0

[ANNOUNCE] GHC 8.6.1-alpha1 available
by Ben Gamari 10 Jul '18

10 Jul '18

The GHC development team is pleased to announce the first alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha1 This is the first release (partially) generated using our new CI infrastructure. One known issue is that the haddock documentation is currently unavailable. This will be fixed in the next alpha release. Do let us know if you spot anything else amiss. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben

4 6

Re: How to use ghc-heap-view of ghc-8.6
by Patrick Dougherty 07 Jul '18

07 Jul '18

Hello, This effort mostly just brought the core of this [1] library into GHC. The main function you will want to try is `getClosureData`,which takes any value and returns the heap representation. There are some tricky aspects about evaluation, but I will refer you to the comments about `Box`s in [1]. As a shameless self-plug, I also wrote a bit about it. The first page is a brief intro to the heap, and the second is an example demonstrating how to track down a leaky accumulator. I also link to a few posts that sent me down this path. This doesn't implement all of the functionality of [1], but it pulls in enough that hopefully it should be a little more stable between GHC versions. Also, you should be able to recreate many of the functions by looking at the source of [1] on hackage. [1] http://hackage.haskell.org/package/ghc-heap-view-0.5.10/docs/GHC-HeapView.h… [2] https://patrickdoc.github.io/heap-view.html Best,Patrick P.S. Sorry about using [1] so many times. Both libraries are called heap-view which makes it a little difficult to distinguish. On Friday, July 6, 2018 10:10 PM, Takenobu Tani <takenobu.hs(a)gmail.com> wrote: Dear devs, I'm interested in ghc-heap-view of ghc-8.6. [1] Is there a document on how to use the ghc-heap-view of ghc-8.6? [1]: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1#Landedinmasterbranch Regards, Takenobu _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

3 3

How to use ghc-heap-view of ghc-8.6
by Takenobu Tani 06 Jul '18

06 Jul '18

Dear devs, I'm interested in ghc-heap-view of ghc-8.6. [1] Is there a document on how to use the ghc-heap-view of ghc-8.6? [1]: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1#Landedinmasterbranch Regards, Takenobu

1 0

Diagonally in Data.Bimap
by Gabor Greif 05 Jul '18

05 Jul '18

Hi! Just searched for a `bimap` variant that simultaneously transforms both components with the same morphism: ``` haskell diag :: Bifunctor p => (a -> b) -> p a a -> p b b diag f = bimap f f ``` I did not find any. Would it make sense to add it? Cheers, Gabor PS: same for profunctors: ``` haskell xmap :: Profunctor p => (a -> b) -> p b a -> p a b ``` PPS: I would have sent this to libraries(a)haskell.org but it seem to be closed group.

2 1

Issues with the large address space allocator and HPC systems with resource limits
by Luis Pedro Coelho 05 Jul '18

05 Jul '18

Dear GHC devs, I hope this is the right forum to bring this up. I am the lead developer of NGLess (https://github.com/ngless-toolkit/ngless a bioinformatics tool, written in Haskell). Several users have complained about not being able to easily use NGLess in an academic cluster environment due to the fact that it allocates 1TB of address space (e.g., https://groups.google.com/forum/#!topic/ngless/9su2E0EdeCc and I have also gotten several private emails on this issue). In particular, many systems are set up with a limit on the address space so that if the job allocates more than the given limit, it is immediately killed. This appears to be the default way to set up SGE, the most widely used batch system. Users are dependent on their sysadmins and lack the permissions to change these settings easily (and may not always be cognizant of the difference between "allocating address space" and "allocating memory"). Using ulimit seem to make the issue disappear on most, but not all, user setups. I have now built NGLess with a version of GHC that was compiled without the large address allocator (using ./configure --disable-large-address-space). At least locally, this seems to run correctly and solve the issue. I assume that there are performance or other reasons to use the large address space allocator as the default, but, right now, for the problem space I am working in, disabling it seems to be a better trade-off. In principle, the RTS that is used for GHC and the one that is used for the programme being linked do not need to be the same. Is there any possibility of making this choice when a programme is linked and not when GHC is compiled? Thank you for all your effort! Luis -- Luis Pedro Coelho | Fudan University | http://luispedro.org PI of Big Data Biology Lab at Fudan University (start mid-2018) http://big-data-biology.org

3 3

Not possible to build debug + prof, oversight or expected?
by Ömer Sinan Ağacan 04 Jul '18

04 Jul '18

I just realized GHC 8.4.2 doesn't ship a debug + prof RTS, and HEAD doesn't build it with release build (no build.mk) or with prof flavor. It seems to me that this is a bug, because some debug files in RTS (e.g. Printer.c) actually check PROFILING macro in a few places and print different stuff depending on that. Anyone know if this is intentional? It's really inconvenient that I can't use debug runtime to debug profiling build issues.. (I also realized that we dont' generate .sos for some ways, which means -dynamic is also don't combine with e.g. -prof) Thanks Ömer

2 1