[GHC] #13104: runRW# ruins join points

[GHC]

#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 `<C(S), C1(U)>`, 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