#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 do quite like this approach. I'm not ready to give it up yet!
I like this game of bad-cop/good-cop with switching roles. Certainly a productive way of investigating an issue :-) * `preInlineUnconditionally`: Well, `int_cxt` certainly is `True` – otherwise `int_cxt && canInlineInLam rhs` would be `False` and inlining would not happen. Are you saying that it should be made `False`? * `completeCall`: Let me try to make sure I understand the reasoning: Normally a join point will not have `occ_in_lam`, because if it would occur under a “normal” lambda, it wouldn’t be a tail-call. The exception are the lambdas on the RHS of a join points, as these are ignored when calculating `occ_in_lam`. But there is an exception to that: Inside a recursive join point we do set `occ_in_lam`. So the occurrence analyzer should detect this? I’ll try.
NB: right at the end (in CorePrep perhaps) we may want to inline them after all, just to reduce clutter and jumps.
Right, I keep that in the back of my mind, but first I need it to actually _not_ inline :-) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14152#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler