#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): I left it out for now, because instruction counts increase. I tried to analyse it, and here is what I found: I read through a lot of core, comparing `-dverbose-core2core` between the version without inlining exit join points at the end, and the version with. In `compress2`, I don’t spot a difference in Core. In `fem` (a big program), there are a fair number of exit join points, but I don’t see anything fishy going on… What I do, how ever, see is exit join points that are called from two positions in the code, where inlining duplicates the code. (Common block elimination might help with that, but #14226 seems to get in the way.) I also see calls to `stg_gc_noregs()` turn into calls to `stg_gc_unpt_r1(R1)`, but I am not sure what that means, or if that is a good thing or a bad thing. I expect that the “useless” unconditional jump to a non-inlined exit join point, which was the motivation for the final inlining, will be eliminated on the Cmm stage without much ado. So the performance measurement says “don't inline”, and looking at the Core, not inlining seems to be fine, and the Cmm also looks better. So in the light of that I think I’ll conclude that the final inlining is neither necessary nor useful. Anyways, the final inline patch still lives in `wip/T14152` for anyone to play with. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14152#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler