#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.
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
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. 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?
`Traverses the AST, simply to find all joinrecs and call 'exitify' on
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 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`
Returning to captures_join_points this can only be true of a call of
Thanks, done. 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