#14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I implemented this transformation; pushed to `wip/T14152` for storage. Don’t review the code too harshly yet, in particular feeding a list of fresh uniques to `maybeLoopify` is a temporary crutch. Observations so far: * Right now I am running this only after loopification. But that is unsatisfactory:[[BR]][[BR]]If we want this, we certainly also want it for functions that are `joinrec` to start with… but where? [[BR]][[BR]] Note that we need access to fresh uniques; this rules out the occurrence analyzer which is currently pure. * Currently, we get the desired transformation, but the next iteration of the simplifier gets rid of it again, in three different ways: * `preInlineUnconditionally` inlines them because they are values, so `canInlineInLam` is true. * `postInlineConditionally` inlines them because they are marked as “work free”. * `completeCall` does inlining at the call-site, again because they are marked as “work free”. It is not clear to me how to fix it. It is not false that they are work-free, and we certainly want to inline these join-points into non- recursive uses (should they for some reason appear). I agree with Simon that floating these things out and keeping them out feels “wrong” in the sense that it fights against the usual working of the simplifier. So maybe back to the drawing board and thinking harder how we can tell the simplifier that it is safe to inline something into the exit path ''inside'' the recursive function, and keep it there? Could we somehow syntactically mark exit paths using a new form of ticks? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14152#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler