#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Where does this occurence of `runRW#` come from? Before adding hacks to the simplifier, it might be sufficient to eta- expand the argument there. For example, instead of {{{ runST (ST st_rep) = case runRW# st_rep of (# _, a #) -> a }}} write {{{ runST (ST st_rep) = case runRW# (\s. st_rep s) of (# _, a #) -> a }}} or, for good measure, {{{ runST (ST st_rep) = case runRW# (oneShot (\s. st_rep s)) of (# _, a #) -> a }}} Have you tried that? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * failure: None/Unknown => Runtime performance bug * milestone: => 8.4.1 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just a warning: I am wary with exposing the `realWorld#` item here. I played with similar (less sophisticated) ideas three years ago, and found that all too easily different invocations of `runRW#` would end up getting mixed up, e.g. by CSE. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): What about adding a new function `runRW##` and allowing -1 to be the phase argument to INLINE? Specifically: {{{#!hs {-# LANGAUGE MagicHash #-} import GHC.Prim runRW## :: forall (r1 :: RuntimeRep). (o :: TYPE r) => State# RealWorld -> (# State# RealWorld, o #) -> (# State# RealWorld, o#) runRW## f = f realWorld# {-# INLINE [-1] runRW## #-} }}} with `runRW# f` having the compulsory unfolding {{{#!hs join $j s = f s {-# INLINE [-1] $j #-} in runRW## @ 'PtrRepLifted @ _ ( \s0 -> $j s }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):

Can we somehow tell GHC that the argument of runRW# is special in the sense that passing a join-point call there is ok?

That would be horribly ad-hoc. We need a better way. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => Comment: Removing milestone as no one is currently actively working on this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thinking about #13104 and #15127, I am gradually being driven to the conclusion that we should treat `runRW#` specially in the simplifier. And perhaps a few other primops (like `maskAsyncExceptions#` too). I just can't see a better way to deal with it. Here's my brain-dump: * Require that the argument of `runRW#` is always eta-expanded, with a one-shot lambda. Similar to the RHS of a join point. This would be an invariant of Core, and checked by Core Lint. * Make `Simplify` push the continuation into the body of the `runRW`, just as it does with join points. So, for example: {{{ case (runRW# (\s.e)) of blah ==> runRW# (\s. case e of blah) }}} * I think that `FloatIn` will do the right thing automatically, provided the lambda is marked one-shot. * Maybe, instead of doing mysterious inlining things in `CorePrep` (as we do now), we could just make the code generator do the Right Thing directly? Just as join bindings look like let-bindings, and in most ways behave like them, but have additional invariants that are checked by Core Lint, so similarly with `runRW# (\s.e)`. I have not yet thought through which other primops should particpate in this party. Certainly the `maskAsyncExceptions#` and unmask families. Probably not `catch#` becuase we have to be so careful about moving code into our out of the scope of an exception handler. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) Comment: I very much agree with what nomeata (comment:10) and simonpj (comment:14) said. We should aim for `loop 0` to be eta-expanded by realising that `runRW#` only calls its argument once. I would begin by looking at how `runRW#` gets its demand signature. It's not listed in primops.txt.pp, so it doesn't seem to be hard-coded into the compiler. It gets 'inlined' in CorePrep and in `cpe_app` there's a test for `runRWKey`. The problem, I guess, is that `runRW#` isn't a recognized primop. On the other hand, it doesn't seem to be a regular identifier, either: If the demand analyser were to look into its definition, it would be given a demand signature of ``, e.g. a signature saying that it calls its argument exactly once with one argument. We want the one-shot (i.e. usage demand) part, but apparently (see Note [runRW magic] in CorePrep) not the strictness part. So, I'd say `runRW#` should be handled as a regular primop like i.e. `catch#` and give it a `lazyApply1Dmd`. If this doesn't help, we could always fall back to more special cases. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Yes, I meant 'make runRW# a proper primop'. It's treated like one by Core anyway. This mostly entails adding it to primops.txt.pp, but I'd suggest grepping for mentions of another primop like `seq#` (lowered in STG, IIRC) and handle it the same way.

To be clear, while currently the demand signature of runRW# is , and you'd rather it be < L, C1(U)>? Why? How is this laziness related to the problem related to the Note [runRW magic]?

I got the note wrong. I was referring to `Note [runRW arg]`, but that note says that we ''should'' make `runRW#` strict and says that we do so in `MkId`. I couldn't find any mention of runRW in there, so that may have been a lie, not sure. So, it seems that `` is actually the correct demand signature. Upon following Phab:D2444, I'm not so sure anymore we should actually handle it as a primop, but rather like `lazy` or `unsafeCoerce#` entirely in `MkId`. Reading wiki:Commentary/PrimOps and wiki:Commentary/Compiler/WiredIn, it seems that currently `runRW#` is a "known-key" thing, but we need it to become a "wired-in" thing to attach useful `IdInfo` such as demand signatures. It should not become a prim-op, because we know how to lower it in CoreToStg as opposed to StgToCmm (effectively 'linking' to an appropriate implementation). It would be great if someone more knowledgable could chime in and confirm my last paragraph. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:19 simonpj]:

So yes, either known-key or wired-in `Id`. We need wired-in if we need IdInfo that won't be inferred; but actually I think the right strictness ''will'' be inferred from its definition, so maybe known-key is enough.

Ah, right. I thought I checked this and expected `runRW#`'s strictness signature to be present in the interface file for `GHC.Exts`, but it wasn't, so I assumed it got special treatment, like wired-in things. It turns out that `f` in the this program {{{ {-# LANGUAGE MagicHash #-} module Foo where import GHC.Magic f = runRW# }}} has the right strictness signature ``. Then it's a little unclear to me why `loop 0` (or the definition of `loop`, at least) isn't eta-expanded. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): whats the current state of play for this bug? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13104#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler