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

 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