- ghc-devs - Haskell.org

Understanding UniqSupply
by Sebastian Graf 23 Jul '18

23 Jul '18

Hi all, I'm trying to understand when it is necessary to `splitUniqSupply`, or even to create my own supply with `mkSplitUniqSupply`. First, my understanding of how `mkSplitUniqSupply` ( https://hackage.haskell.org/package/ghc-8.4.1/docs/src/UniqSupply.html#mkSp…) works is as follows: - The `unsafeInterleaveIO` makes it so that `genSym` is actually forced before any of the recursive calls to `mk_split` force their `genSym`, regardless of evaluation order - This guarentees a certain partial order on produced uniques: Any parent `UniqSupply`'s `Unique` is calculated by a call to compiler/cbits/genSym.c#genSym() before any `Unique`s of its offsprings are - The order of `Unique`s on different off-springs of the same `UniqSupply` is determined by evaluation order as a result of `unsafeInterleaveIO`, much the same as when we create two different `UniqSupply`s by calls to `mkSplitUniqSupply` - So, `unfoldr (Just . takeUniqFromSupply) us) !! n` is always deterministic and strictly monotone, in the sense that even forcing the expression for n=2 before n=1 will have a lower `Unique` for n=1 than for n=2. - This is of course all an implementation detail These are the questions that bother me: 1. `takeUniqSupply` returns as 'tail' its first off-spring, whereas `uniqsFromSupply` always recurses into its second off-spring. By my intuition above, this shouldn't really make much of a difference, so what is the motivation for that? 2. The docs state that the character tag/domain/prefix in the call to `mkSplitUniqSupply` should be unique to guarantee actual uniqueness of produced `Unique`s. Judging from the implementation of `genSym`, which is unaware of the specific domain to draw the next unique from, this is an unnecessarily strong condition?! Also there are multiple places in the code base spread over module boundaries even (e.g. CorePrep, SimplCore) that call `mkSplitUniqSupply` with the same character anyway. Maybe there should at least be some clarifying comment on why this isn't a problem? 3. Judging from SimplCore, we probably want to `splitUniqSupply` after each iteration/transformation, either through a call to `splitUniqSupply` or `getUniqueSupplyM`. Is that right? 4. What's the need for splitting anyway? I suspect it's a trick to avoid state threading that would be necessary if we just had `type UniqSupply = [Unique]`. Would that really be a bad thing, considering we mostly work in `UniqSM` anyway? Is there anything else to it? Happy to hear from you! Cheers Sebastian

2 2

Re: [ANNOUNCE] GHC 8.6.1-alpha2 available
by Ryan Scott 21 Jul '18

21 Jul '18

Presumably, you're compiling this program outside of a git repository, and so the Template Haskell splice $(gitHash) evaluates to "UNKNOWN" at compile time. Here is an even more minimal example, which does not depend on gitrev: f :: () f = case "UNKNOWN" of "UNKNOWN" -> () _ -> () This, when compiled with GHC 8.6.1 or later, gives the same warning: Test.hs:4:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: _ -> ... | 4 | _ -> () | ^^^^^^^^^^^^^^^ This, I would argue, is a correct error message. The string literal "UNKNOWN" is, well, statically known to be "UNKNOWN", so GHC knows that that catch-all case cannot be reached. (See [1] for the commit which introduced this check.) Granted, this makes things slightly inconvenient for your purposes, since in your actual program, $(gitHash) might evaluate to *different* things at compile time depending on the directory you compile it in. I'd recommend rewriting the commitInfo function to pattern guards: commitInfo :: Maybe String commitInfo | hash == "UNKNOWN" = Nothing | otherwise = Just hash where hash = $(gitHash) Since that does not trigger -Woverlapping-patterns. (Granted, it's possible that GHC could become much smarter in the future and be able to detect that that `otherwise` case is unreachable when $(gitHash) evaluates to "UNKNOWN" at compile time. But GHC certainly isn't that smart today!) Ryan S. ----- [1] http://git.haskell.org/ghc.git/commit/1f88f541aad1e36d01f22f9e71dfbc247e655…

2 1

[ANNOUNCE] GHC 8.6.1-alpha2 available
by Ben Gamari 21 Jul '18

21 Jul '18

The GHC development team is pleased to announce the second alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha2 This alpha fixes many of the bugs reported in the first alpha and brings many of the core libraries to their (hopefully) final release versions. Unfortunately, the documentation troubles affecting the first alpha haven't quite been resolved in this release. Consequently you will again find there is no documentation uploaded. However, let us know if anything else is amiss. Thanks for your help! Cheers, - Ben

3 2

isAlive() too conservative -- does it cause leaks?
by Ömer Sinan Ağacan 19 Jul '18

19 Jul '18

Hi Simon, Currently isAlive considers all static closures as being alive. The code: // ignore static closures // // ToDo: This means we never look through IND_STATIC, which means // isRetainer needs to handle the IND_STATIC case rather than // raising an error. // // ToDo: for static closures, check the static link field. // Problem here is that we sometimes don't set the link field, eg. // for static closures with an empty SRT or CONSTR_NOCAFs. // if (!HEAP_ALLOCED_GC(q)) { return p; } I'd expect this to cause leaks when e.g. key of a WEAK is a static object. Is this not the case? I think this is easy to fix but I may be missing something and wanted to ask before investing into it. The idea: - Evacuate all static objects in evacuate() (including the ones with no SRTs) (assuming all static objects have a STATIC_FIELD, is this really the case?) - In isAlive() check if (STATIC_FIELD & static_flag) != 0. If it is then the object is alive. Am I missing anything? Thanks, Ömer

2 2

type-checker plugin API/behaviour change
by Christiaan Baaij 18 Jul '18

18 Jul '18

Hi devs, Currently, type-checker plugins get to tell the solver its progress using a [TcPluginResult]( http://hackage.haskell.org/package/ghc-8.4.1/docs/TcRnTypes.html#t:TcPlugin… ): ``` data TcPluginResult = TcPluginContradiction [Ct] -- ^ The plugin found a contradiction. -- The returned constraints are removed from the inert set, -- and recorded as insoluble. | TcPluginOk [(EvTerm,Ct)] [Ct] -- ^ The first field is for constraints that were solved. -- These are removed from the inert set, -- and the evidence for them is recorded. -- The second field contains new work, that should be processed by -- the constraint solver. ``` So when asked to solve a _set_ of constraints, a tc plugin basically gets to say: A) This _one_ constraint out of the entire set is wrong, or B) The following _subset_ of constraints is solved (plus some new wanted constraints) Supposedly, picking A leads to better error messages when a constraint is obviously bad (i.e. Int ~ Char). However, the issue is that when a tc plugin picks A, then it will not be called again for the whole set of constraint it originally got; which in my use-case basically leads to a complete set of (actually solvable) unsolved constraints. This is "bad" because it leads to very confusing error messages, when 1. Start with a correct program: All constraints solvable => no errors reported 2. Add one line of code that doesn't type check 3. All constraints unsolvable => errors reported in parts of the program that used to type-check. I thought of multiple possible solutions, but changing TcPluginResult to: ``` data TcPluginResult = TcPluginResult { contradictions :: [Ct] -- ^ All of the contradictions the plugin found , solved :: [(EvTerm,Ct)] -- ^ Constraints that were solved , new :: [Ct] -- ^ New work to be processed by the rest of the constraint solver } ``` seems the best one as it allows a tc plugin to report _all_ the constraints that are bad, and _all_ the constraints that are bad. Thoughts? Perhaps a better solution? Thanks, Christiaan

2 1

Write barrier for stack updates?
by Ömer Sinan Ağacan 18 Jul '18

18 Jul '18

Hi Simon, I'm a bit confused about stack updates in generated code and write barriers. Because stacks are mutable (we push new stuff or maybe even update existing frames?) it seems to me that we need one these two, similar to other mutable objects: - Always keep all stacks in mut_lists - Add write barriers before updates However looking at some of the primops like catch# and the code generator that generates code that pushes update frames I can't see any write barriers and the GC doesn't always add stacks to mut_lists (unlike e.g. MUT_ARR_PTRS). I also thought maybe we add a stack to a mut_list when we switch to the TSO that owns it or we park the TSO, but I don't see anything relevant in Schedule.c or ThreadPaused.c. So I'm lost. Could you say a few words about how we deal with mutated stacks in the GC, so that if an old stack points to a young object we don't collect the young object in a minor GC? Thanks, Ömer

2 2

submodule repos on GitHub
by Richard Eisenberg 17 Jul '18

17 Jul '18

Hi devs, The Newcomers page (https://ghc.haskell.org/trac/ghc/wiki/Newcomers) recommends cloning GHC with > git clone --recursive git://github.com/ghc/ghc I believe my students did this with success several weeks ago. But trying it again today leads to trouble with some submodules, e.g.: > Cloning into '/Users/rae/ltemp/ghc-test/libraries/Cabal'... > fatal: remote error: > ghc/packages/Cabal is not a valid repository name > Email support(a)github.com for help > fatal: clone of 'git://github.com/ghc/packages/Cabal.git' into submodule path '/Users/rae/ltemp/ghc-test/libraries/Cabal' failed > Is there something wrong in the internets? Or should we update the Newcomers page? Thanks, Richard

4 6

Cmm learning tools
by Daniel Cartwright 17 Jul '18

17 Jul '18

Hello all, I've recently become interested in learning Cmm, but cannot seem to find any concrete learning resources or extensive papers. It doesn't help that the web seems to contain a lot of useless information for a newcomer to Cmm. If anyone could provide some reading material about Cmm, I would be most grateful.

3 5

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

17 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