#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 simonpj):
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.
Well, now I understand better, I do quite like this approach. I'm not ready to give it up yet! * `preInlineUnconditionally`. Yes `caonInlineInLam` is true, but `int_cxt` (short for "interesting context") is probably false. * `completeCall`: I think we may be saying "never inline a join point that appears on the RHS of a recursive join point". We can make that happen by giving its unfolding an `UnfoldingGuidance` of `UnfNever`. We can spot that it apperas on the RHS of a recursive join point because its occ-info will have `occ_in_lam` = True. * `postInlineUnconditionally`. As the comments say, the main goal here is to solve this {{{ -- let x = f y in -- case v of -- True -> case x of ... -- False -> case x of ... }}} Here we want to inline `x`, otherwise it allocates a thunk. But join points do not allocate thunks; perhaps we can simply not do `postInlineUnconditionally` on the `OneOcc` branch? And in fact giving it an `UnfoldingGuidance` of `UnfNever` will also stop it inlining. NB: right at the end (in `CorePrep` perhaps) we may want to inline them after all, just to reduce clutter and jumps. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14152#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler