[GHC] #14152: Float exit paths out of recursive functions

[GHC]

#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