#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 chessai): Replying to [comment:16 sgraf]:
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.
This is pretty useful information, thanks! When you say 'handle _like_ a regular primop', do you mean to say 'make it a primop'? To be clear, while currently the demand signature of `runRW#` is `<C(S), C1(U)>`, and you'd rather it be `< L, C1(U)>`? Why? How is this laziness related to the problem related to the Note [runRW magic]? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13104#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler