- ghc-devs - Haskell.org

CI: Choice of base commit for perf comparisons
by Joachim Breitner 22 Dec '21

22 Dec '21

Hi, the new (or “new”?) handling of perf numbers, where CI just magically records and compares them, without us having to manually edit the `all.T` files, is a big improvement, thanks! However, I found the choice of the base commit to compare against unhelpful. Assume master is at commit M, and I start a feature branch and MR with commit A. CI runs, and tells me about a performance regressions, and CI is red. I now fix the issue and push commit B to the branch. CI runs, but it picks A to compare against, and now it is red because of an seemingly unexpected performance improvement! I would have expected that all CI runs for this MR to compare the performance against the base branch on master, and to look for perf change notices in all commit messages in between. I see these advantages: * The reported perf changes correspond to the changes shown on the MR page * Green CI = the MR is ready (after squashing) * CI will have numbers for the base commit more reliably (else, if I push commit C quickly after B, then the job for B might be cancelled and Ci will report changes of C against A instead of B, which is unexpected). I have used this logic of reporting perf changes (or any other “differential CI”) against the base branch in the Motoko project and it was quite natural. Would it be desirable and possible for us here, too? (A possible rebuttal might be: we don’t push new commits to feature branches, but always squash and rebase, as that’s what we have to do before merging anyways. If that’s the case then ok, although I generally lean to having chronological commits on feature branches and a nice squashed commit on master.) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Merge request merge timing
by Ben Gamari 21 Dec '21

21 Dec '21

Hello all, Recently there have been a few instances where merge requests were merged extremely quickly (e.g. within an hour of the MR being opened). While prompt review is a good thing, we also want to make sure that all potentially interested reviewers have an opportunity to comment. In this vein, I propose that we wait at least 24 hours from the time an MR is opened before sending it to Marge. I have documented this to the merge-request review guidelines on the Wiki [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/gitlab/merge-requests

1 0

[PSA] Patches to Haddock regarding GHC development move to GitLab!
by Hécate 17 Dec '21

17 Dec '21

Hi everyone, just a PSA from the Haddock team and GHC release managers to warn everyone that, effective immediately, patches to Haddock needed for GHC merge requests are not to be directed to GitHub anymore. Those patches are to be sent to the GitLab mirror: https://gitlab.haskell.org/ghc/haddock. I will try and warn folks who currently have PRs opened on GitHub targeting ghc-head, but please know that they'll be closed in the next few days. Have a great end of the week, Hécate, for the Haddock Team. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

2 1

Transparently hooking into the STG stack to validate an escape analysis
by Sebastian Graf 17 Dec '21

17 Dec '21

Hi Devs, my master's student Sebastian and I (also Sebastian :)) are working on an escape analysis in STG, see https://gitlab.haskell.org/ghc/ghc/-/issues/16891#note_347903. We have a prototype for the escape analysis that we want to validate/exploit now. The original plan was to write the transformation that allocates non-escaping objects on the STG stack. But that is quite tricky for many reasons, one of them being treatment of the GC. This mail is rather lengthy, so I suggest you skip to "What we hope could work" and see if you can answer it without the context I provide below. If you can't, I would be very grateful if you were willing to suffer through the exposition. # Instrumentation So instead we thought about doing a (easily changed and thus versatile) instrumentation-based approach: Assign a sequence number to every instantiation (a term I will use to mean "allocation of g's closure") of things that we our analysis determines as escaping or non-escaping, such as STG's let bindings (focusing on non-let-no-escape functions for now). (One sequence number *per allocation* of the let binding's closure, not based on its syntactic identity.) Then, we set a bit in a (dynamically growing) global bit vector whenever the let "RHS is entered" and then unset it when we "leave the let-body". Example: f = \x y -> let { g = [y] \z -> y + z; } in g x Here, our analysis could see that no instantiation (which I say instead of "allocation of g's closure") of g will ever escape its scope within f. Our validation would give a fresh sequence number to the instantiation of g whenever f is called and store it in g's closure (which we arrange by piggy-backing on -prof and adding an additional field to the profiling header). Then, when g's RHS is entered, we set the bit in the global bit vector, indicating "this instantiation of g might escape". After leaving the RHS of g, we also leave the body of the defining let, which means we unset the bit in the bit vector, meaning "every use so far wasn't in an escaping scenario". So far so good. Modifying the code upon entering g takes a bit of tinkering but can be done by building on TickyTicky in StgToCmm. But what is not done so easily is inserting the continuation upon entering the let that will unset the bit! # What doesn't work: Modifying the Sequel At first, we tried to modify the sequel <https://gitlab.haskell.org/ghc/ghc/-/blob/4c6985cc91b9cf89b393f69c9a603e8df…> of the let-body to an `AssignTo`. That requires us to know the registers in which the let-body will return its results, which in turn means we have to know the representation of those results, so we have to write a function `stgExprPrimRep :: GenStgExpr p -> [PrimRep]`. Urgh! We were very surprised that there was no such function. And while we tested our function, we very soon knew why. Consider the following pattern synonym matcher: GHC.Natural.$mNatJ# :: forall {rep :: GHC.Types.RuntimeRep} {r :: TYPE rep}. GHC.Num.Natural.Natural -> (GHC.Num.BigNat.BigNat -> r) -> ((# #) -> r) -> r = {} \r [scrut_sBE cont_sBF fail_sBG] case scrut_sBE of { GHC.Num.Natural.NS _ -> fail_sBG GHC.Prim.(##); GHC.Num.Natural.NB ds_sBJ -> let { sat_sBK :: GHC.Num.BigNat.BigNat = CCCS GHC.Num.BigNat.BN#! [ds_sBJ]; } in cont_sBF sat_sBK; }; Note how its result is representation-polymorphic! It only works because our machine implementation allows tail-calls. It's obvious in hindsight that we could never write `stgExprPrimRep` in such a way that it will work on the expression `cont_sBF sat_sBK`. So the sequel approach seems infeasible. # What we hope could work: A special stack frame The other alternative would be to insert a special continuation frame on the stack when we enter the let-body (inspired by stg_restore_cccs). This continuation frame would simply push all registers (FP regs, GP regs, Vec regs, ...) to the C stack, do its work (unsetting the bit), then pop all registers again and jump to the topmost continuation on the STG stack. Example: f :: forall rep (r :: TYPE rep). Int# -> (Int# -> r) -> r f = \x g -> let { h = [x] \a -> x + a; } in case h x of b { __DEFAULT -> g b } We are only interested in unsetting the bit for h here. Consider the stack when entering the body of h. caller_of_f_cont_info <- Sp Now push our special continuation frame: caller_of_f_cont_info seq_h unset_bit_stk_info <- Sp E.g., the stack frame contains the info pointer and the sequence number. (Btw., I hope I got the stack layout about right and this is even possible) Then, after we entered the continuation of the __DEFAULT alt, we do a jump to g. Plot twist: g returns an unboxed 8-tuple of `Int#`s (as caller_of_f_cont_info knows, but f certainly doesn't!), so before it returns it will push two args on the stack (correct?): caller_of_f_cont_info seq_h unset_bit_stk_info unboxed tuple component 7 unboxed tuple component 8 <- Sp And then `g` jumps directly to the entry code for `unset_bit_stk_info` (which does the register saving I mentioned), which absolutely can't figure out from Sp alone where seq_h is. Darn! I think Luite's recent work on the StgToByteCode had to work around similar issues, I found this wiki page <https://gitlab.haskell.org/ghc/ghc-wiki-mirror/-/blob/master/Unboxed-Tuples…>. But we aren't in a position where we know the representation of `r` *at all*! So our idea was to scan the stack, beginning from `Sp`, until I find `unset_bit_stk_info`, giving us the following situation: caller_of_f_cont_info seq_h unset_bit_stk_info <- Bp unboxed tuple component 7 unboxed tuple component 8 <- Sp I suggestively named the register in which we store the result Bp in analogy to the traditional base pointer. This information would be enough to unset the bit at index seq_h and then copy the unboxed tuple components 7 and 8 up by two words: caller_of_f_cont_info unboxed tuple component 7 unboxed tuple component 8 <- Sp Then jump to caller_of_f_cont_info, which knows what to make of the stack and the register state. The stack scanning is horrible and too brittle and slow for a production setting, as any of the unboxed tuple components could have the same bit pattern as `unset_bit_stk_info`. We simply hope that is never the case and it's fine for the purposes of a quick-and-dirty instrumentation. QUESTION 1: What do you think? Could this work? Can you anticipate pit falls of this approach? # What about Thunks and StgRhsCon? QUESTION 2: The instrumentation as described won't work for Thunks (which are only entered once) and constructor applications (like sat_sBK in the BigNat matcher above). Not sure how to change that without incurring huge performance hits (by deactivating memoisation). Ideas are welcome here. Thanks for reading this far. I hope you could follow and are now fizzing with excitement because you have a much better idea of how to do this and will let me know :) Sebastian

2 4

Re: Thoughts on async RTS API?
by Cheng Shao 16 Dec '21

16 Dec '21

Hi Alex, Thanks for reminding. hs_try_put_mvar() wouldn't work for our use case. If the C function finishes work and calls hs_try_put_mvar() synchronously, in Haskell takeMVar wouldn't block at all, which is all fine. However, if the C function is expected to call hs_try_put_mvar() asynchronously, the non-threaded RTS will hang! Here's a minimal repro. It works with non-threaded RTS at first, but if you change scheduleCallback() in C so hs_try_put_mvar() is only invoked in a detached pthread, then the program hangs. The proposed async RTS API and related scheduler refactorings can't be avoided, if the MVar is intended to be fulfilled in an async manner, using the non-threaded RTS, on a platform with extremely limited syscall capabilities. ```haskell import Control.Concurrent import Control.Exception import Foreign import Foreign.C import GHC.Conc main :: IO () main = makeExternalCall >>= print makeExternalCall :: IO CInt makeExternalCall = mask_ $ do mvar <- newEmptyMVar sp <- newStablePtrPrimMVar mvar fp <- mallocForeignPtr withForeignPtr fp $ \presult -> do (cap,_) <- threadCapability =<< myThreadId scheduleCallback sp cap presult takeMVar mvar peek presult foreign import ccall "scheduleCallback" scheduleCallback :: StablePtr PrimMVar -> Int -> Ptr CInt -> IO () ``` ```c #include "HsFFI.h" #include "Rts.h" #include "RtsAPI.h" #include <unistd.h> #include <pthread.h> struct callback { HsStablePtr mvar; int cap; int *presult; }; void* callback(struct callback *p) { usleep(1000); *p->presult = 42; hs_try_putmvar(p->cap,p->mvar); free(p); return NULL; } void scheduleCallback(HsStablePtr mvar, HsInt cap, int *presult) { pthread_t t; struct callback *p = malloc(sizeof(struct callback)); p->mvar = mvar; p->cap = cap; p->presult = presult; // pthread_create(&t, NULL, callback, p); // pthread_detach(t); callback(p); } ``` On Thu, Dec 16, 2021 at 12:10 PM Alexander V Vershilov <alexander.vershilov(a)gmail.com> wrote: > > Hello, replying off-the thread as it would be basically an offtopic. > > But you can achieve the solution using MVars only. > The idea is that you can call mkStablePtr on the MVar that way it will > not be marked as dead, so RTS will not exit. > Then you can use hs_try_put_mvar in C thread to call the thread back. > > On Wed, 15 Dec 2021 at 05:07, Cheng Shao <cheng.shao(a)tweag.io> wrote: > > > > 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 > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > -- > Alexander

1 0

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