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

 Replying to [comment:29 simonpj]:
 > > I left it out for now, because instruction counts increase
 >
 > So, just to be sure: allocation counts did not change?

 Nope. Byte-for-byte identical.

 > > What I do, how ever, see is exit join points that are called from two
 positions in the code, where inlining duplicates the code.
 >
 > What if you inline only join points that are called once?   So that no
 code duplication is involved.

 I doubt that the code duplication is the real culprit here. More likely
 things like different order of blocks leading to different decision later
 in the code generation, e.g. in the register allocator, leading to less or
 more register pressure and different registers being saved? Do you know
 the difference between `stg_gc_noregs()` and `stg_gc_unpt_r1(R1)`?

 > I'm having a hard time seeing why that should do anything bad.  And it
 can do something good...  if you have
 > {{{
 > join j x = ...y...
 > in
 >   ...jump j v...
 > }}}
 > then `y` will get pushed onto the stack at the `join`, so that its RHS
 knows where to find it. If it's inlined that may not happen.  So may be
 more than just eliminating a jump.

 Well, according to the numbers it's not happening.

 Remember that the `jump` to an exit point is almost always going to the
 right-hand-side of a case alternative. Which is, as far I as I can tell,
 already a jump target, so the `y` in your example would have to be pushed
 on the stack just the same, woudn’t it?

 I understand that this is all a bit unsatisfying intellectually, but I
 don’t want to sink more time into this, at least not without concrete
 examples or other evidence that show that what we are doing now is indeed
 bad.

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