[GHC] #13104: runRW# ruins join points

[GHC]

#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