- ghc-devs - Haskell.org

Thoughts on async RTS API?
by Cheng Shao 15 Dec '21

15 Dec '21

Hi devs, To invoke Haskell computation in C, we need to call one of rts_eval* functions, which enters the scheduler loop, and returns only when the specified Haskell thread is finished or killed. We'd like to enhance the scheduler and add async variants of the rts_eval* functions, which take C callbacks to consume the Haskell thread result, kick off the scheduler loop, and the loop is allowed to exit when the Haskell thread is blocked. Sync variants of RTS API will continue to work with unchanged behavior. The main intended use case is async foreign calls for the WebAssembly target. When an async foreign call is made, the Haskell thread will block on an MVar to be fulfilled with the call result. But the scheduler will eventually fail to find work due to empty run queue and exit with error! We need a way to gracefully exit the scheduler, so the RTS API caller can process the async foreign call, fulfill that MVar and resume Haskell computation later. Question I: does the idea of adding async RTS API sound acceptable by GHC HQ? To be honest, it's not impossible to workaround lack of async RTS API: reuse the awaitEvent() logic in non-threaded RTS, pretend each async foreign call reads from a file descriptor and can be handled by the POSIX select() function in awaitEvent(). But it'd surely be nice to avoid such hacks and do things the principled way. Question II: how to modify the scheduler loop to implement this feature? Straightforward answer seems to be: check some RTS API non-blocking flag, if present, allow early exit due to empty run queue. Thanks a lot for reading this, I appreciate any suggestions or questions :) Best regards, Cheng

2 2

Coping with multiple meanings of `<>`
by Norman Ramsey 15 Dec '21

15 Dec '21

I find myself wanting to define instances of Semigroup (and Monoid) in a file that also imports GHC.Utils.Outputable and its `<>` operation on SDocs. At the moment I am dealing with the incompatibility by hiding the Outputable version and instead of writing `s1 <> s2` I write `hcat [s1, s2]`. This workaround seems ugly and vaguely embarrassing. How are others dealing with this issue? Would it be sensible simply to make SDoc an instance of Semigroup (and Monoid), or would we be concerned about potential additional overhead at compile time? Norman

2 1

GitLab upgrade starting soon
by Ben Gamari 13 Dec '21

13 Dec '21

Hi all, I will be performing an upgrade of gitlab.haskell.org in roughly 30 minutes if there are no objections. I expect the down-time to be on the order of 20 minutes. Cheers, - Ben

1 0

Alternatives for representing a reverse postorder numbering
by Norman Ramsey 09 Dec '21

09 Dec '21

Reverse postorder numbering is a superpower for control-flow analysis and other back-end things. For example, - In a reducible flow graph, a node Q is a loop header if and only if it is targeted by an edge P -> Q where Q's reverse postorder number is not greater than P's. - If a loop has multiple exits, the reverse postorder numbering of the exit nodes tells exactly the order in which the nodes must appear so they can be reached by multilevel `exit`/`break` statements, as are found in WebAssembly. - Reverse postorder numbers enable efficient computations of set intersection for dominator analysis. One could go on. In a perfect world, our representation of control-flow graphs would provide a place to store a reverse postorder number for each (reachable) basic block. Alas, we live in an imperfect world, and I am struggling to figure out how best to store reverse postorder numbers for the blocks in a `GenCmmGraph`. 1. One could apply ideas from "trees that grow" to the `Block` type from `GHC.Cmm.Dataflow.Block`. But this type is already one of the more complicated types I have ever encountered in the wild, and the thought of further complexity fills me with horror. 2. One could generalize quite a few types in `Cmm`. In particular, one could create an analog of the `GenCmmGraph` type. The analog, instead of taking a node type `n` as its parameter, would take a block type as its parameter. It would use `Graph'` as defined in `GHC.Cmm.Dataflow.Graph`. This change would ripple into `GHC.Cmm.Dataflow` without doing a whole lot of violence to the code that it there. It would then become possible to do dataflow analysis (and perhaps other operations) over graphs with annotated blocks. It's worth noting that the `Graph'` representation already exists, but it doesn't seem to be used anywhere. I'm not sure how it survived earlier rounds of culling. 3. One could simple build an auxiliary `LabelMap` that includes the reverse postorder number of every node. This idea bugs me a bit. I don't love spending O(log N) steps twice every time I look to see the direction of a control-flow edge. But what I *really* don't love is what happens to the interfaces. I can compute the reverse postorder map twice, or I can pollute my interfaces by saying "here is the dominator relation, and by the way, here also are the reverse postorder numbers, which I had to compute." I'm currently using alternative 3: when I need reverse postorder numbers, I call `revPostorderFrom` (defined in `GHC.Cmm.Dataflow.Graph`), then zip with `[1..]`. But I'm really tempted by alternative 2, which would allow me to, for example, define a graph annotated with reverse postorder numbers, then do both the dominator analysis and my translation on that graph. How deep into the weeds should I go? Make dataflow analysis even more polymorphic? or learn to love `LabelMap`? Norman

3 3

Concrete#, SpecialPred, and CtEvidence invariants
by Alexis King 09 Dec '21

09 Dec '21

Hi all, After a recent off-list conversation, I’ve been exploring using the new SpecialPred mechanism to implement a custom constraint, but I’ve run into some questions regarding evidence for CSpecialCan constraints. Specifically, I’m uncertain about how to use them while satisfying Note [CtEvidence invariants] in GHC.Tc.Types.Constraint. Specifically, the Note in question states that ctev_pred must always be kept in sync with the type of the evidence. For example, if ctev_dest for a wanted constraint is a coercion hole, ctev_pred must be `varType (coHoleCoVar hole)`. However, this seems rather odd in the case of Concrete# constraints, since the evidence for a `Concrete# (ty :: ki)` constraint is a coercion of type `ty ~# alpha`. In canNonDecomposableConcretePrim in GHC.Tc.Solver.Canonical, setCtEvPredType is used to update the type of a CSpecialCan constraint, and setCtEvPredType automatically maintains the CtEvidence invariant mentioned above. But this results in setCoHoleType being used to modify the type of the CoVar from `ty ~# alpha` to `Concrete# (ty :: ki)`, which does not make much sense, since that is definitely *not* the type of the CoVar. As far as I can tell, the only reason that doesn’t cause Core Lint errors is that the modified CoVar is never actually used, only the original one is. This suggests to me that the invariant is not actually the right one. The Note suggests that the reason the invariant exists is that the type must be kept fully-zonked… which in turn suggests that perhaps fully-zonkedness is the invariant that’s actually desired. In that case, ctev_pred would *not* necessarily always be a cache for the type of the evidence, since in the case of Concrete#, the evidence has a different type (though for other types of constraints the old invariant would still coincidentally hold). Rather, it would be the responsibility of canNonDecomposableConcretePrim to merely ensure the evidence’s type is appropriately zonked. Does this all sound right to people? If so, I will update the Note with the modified invariant and update the code to match. Alexis

2 2

is there a way to alter every line of an SDoc?
by Norman Ramsey 06 Dec '21

06 Dec '21

I'm emitting code in which I want to prettyprint the contents of a Cmm Block as a comment, by which I mean putting `--` to the left of *each* line of the rendered Cmm Block. Using GHC.Utils.Outputable, is this even possible? How would I tackle it? (The Haddock page does not suggest any obvious combinators.) Norman

2 2

Why and How the External STG interpreter is Useful (Online presentation, Dec 2, Friday, 17:00 UTC)
by Csaba Hruska 05 Dec '21

05 Dec '21

Hello, Today I'll do a presentation about the external stg interpreter. If you are interested please join and ask questions. https://skillsmatter.com/meetups/13654-haskell-stg-interp Regards, Csaba Hruska Abstract: Haskell: Why and How the External STG Interpreter is Useful The external STG interpreter is a from scratch implementation of the STG machine in Haskell. Currently it supports almost all GHC primops and RTS features. It can run real world Haskell programs that were compiled with GHC Whole Program Compiler (GHC-WPC). GHC-WPC is a GHC fork that exports the whole program STG IR. The external STG interpreter is an excellent tool to study the runtime behaviour of Haskell programs, i.e. it can run/interpret GHC or Pandoc. The implementation of the interpreter is in plain simple Haskell, so it makes compiler backend and tooling development approachable for everyone. It already has a programmable debugger which supports step-by-step evaluation, breakpoints and execution region based inspection. It also can export the whole program memory state and call-graphs to files for further investigation. These features make it easy to find a memory leak or to identify a performance bottleneck in a large real world Haskell application. https://github.com/grin-compiler/ghc-whole-program-compiler-project

3 6

Recognizing default method implementations
by Erdi, Gergo 02 Dec '21

02 Dec '21

PUBLIC Hi, Is there a way to recognize that an Id / Var refers to a default method implementation, e.g. $dm/= in the following? $dm/= :: forall a. Eq a => a -> a -> Bool [GblId, Arity=3, Unf=OtherCon []] $dm/= = \ (@a_ahz) ($dEq_sI6 [Occ=Once1] :: Eq a_ahz) (x_sI7 [Occ=Once1] :: a_ahz) (y_sI8 [Occ=Once1] :: a_ahz) -> case == @a_ahz $dEq_sI6 x_sI7 y_sI8 of { False -> True; True -> False } Thanks, Gergo This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer. Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same. Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.

2 2

GitLab likes Chrome more than Firefox
by Richard Eisenberg 30 Nov '21

30 Nov '21

Hi all, On a tip from Ben, I'm using Chrome to review a large patch (!7033 for the curious). It is qualitatively better than Firefox, my usual tool. I will be routinely using Chrome to review large patches from now on. You may want to, too. Richard

2 1

(no subject)
by Harendra Kumar 26 Nov '21

26 Nov '21

Hi GHC devs, While compiling the primitive package using ghc head I ran into the following error: Data/Primitive/Types.hs:265:870: error: • Couldn't match type ‘Word64#’ with ‘Word#’ Expected: Word64_# Actual: Word64# • In the fourth argument of ‘setWord64Array#’, namely ‘x#’ In the first argument of ‘internal’, namely ‘(setWord64Array# arr# i n x#)’ In the first argument of ‘unsafeCoerce#’, namely ‘(internal (setWord64Array# arr# i n x#))’ | 265 | derivePrim(Word64, W64#, sIZEOF_WORD64, aLIGNMENT_WORD64, | Any idea what this is and how it can be fixed? -harendra

2 2