[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:  patch
        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):

 > In the top-level exitifyProgram I think we make no attempt to exitify
 top level recursive functions. That's fine, but say so.

 There are no top-level join points. Note that exitification does not make
 new join points.

 But I added a one-line comment to remind of this fact.

 >  Then in go of exitifyProgram I think we are looking at the RHS of a
 top-level function, and applying goBind to every binding within it. (NB:
 goBind calls go to deal with the RHS of the bindings; I'd be inlined do
 that in go so that goBind gets the post-exitify bindings.)

 Not sure I follow the NB. Isn’t it the common idiom to have a `goExpr`
 (here `go`), and a `goBind` that are mutually recursive?

 >   Mysteriously we do not exitify the RHS of a case alternative (goAlts).
 This exception seems highly mysterious, possibly a bug?

 Not mysterious at all: I exitify `joint points`, i.e. recursive binders.
 The RHS of a case alternative is just an expression – nothing to exitify
 there. And `goAlts` calls `go` just fine…

 I am actually not sure what is confusing about `exitifProgram`. Its
 comment says

 > `Traverses the AST, simply to find all joinrecs and call 'exitify' on
 them.`

 and it does precisely that.


 >   There is some magic in go in exitify to pick out the ones we want to
 exitify. Explaining these conditions in a note would be good

 Every of the three conditions has a comment, and the first two point to
 notes…

 > Maybe it'd be clearer to say  … I'd put this function in `SimplUtils` or
 something.

 done

 >  The occurrence analyser sets occ-info. No one else should. What happens
 if you leave this out?

 If I leave this out, then until the next run of the occ analyzer,
 `isExitJoinId` will not detect an exit join point as such. From your
 clarification about that function I conclude that it shall only be used by
 the simplifier, which runs the occ analyzer before, so it looks like I can
 leave this out. Will try.

 >  Can we rename `args` to `abs_vars`, the variables over which we are
 going to abstract?

 Of course, sorry for that.

 > You probably need to topologically sort those `abs_vars`

 Thanks, done.

 >  Returning to captures_join_points this can only be true of a call of
 form j e1 .. en

 I don’t think that’s true. What if I exitify something like
 {{{
   case b of True -> jump j 1; False -> jump j 2
 }}}
 This is not of this form, and I need to check whether I can actually
 abstract over this?

 > It looks to me that you don't even attempt to turn the whole of <big>
 into an exit point. Instead you recurse into it. But why don't you?

 Sure I do: The case
 {{{
         -- We have something to float out!
 }}}
 would apply there just fine.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14152#comment:39>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler