[GHC] #15560: Full laziness destroys opportunities for join points

[GHC]

#15560: Full laziness destroys opportunities for join points
-------------------------------------+-------------------------------------
        Reporter:  AndreasK          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
  (CodeGen)                          |
      Resolution:                    |             Keywords:  JoinPoints
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #14287 #13286     |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by AndreasK):

 Replying to [comment:11 simonpj]:
 > > Ideally we would combine the checks for all branches into a single one
 to begin with.
 >
 > (Another possibility that looks unattractive, and that I have not
 explored: put the heap check after returning from evaluating `x` but
 before doing the case-analysis to decide which branch to take.  That might
 reduce code size, but would never eliminate a heap check altogether;
 indeed it might put one in the code path that was not there before, for a
 branch that did not allocate at all.)

 The obvious solution seems to me is to simply limit this to cases where
 all branches allocate. This would reduce code size while coming with few
 penalties.
 It would probably make sense to special case two other scenarios:
 * If the difference in allocation is huge.
 * If the non allocating branches are bottoming (eg pattern match
 failures).

 But I'm not sure how easy it ease to check these conditions during
 StgToCmm generation. I'm not really familiar with that part of codegen
 yet.

 > I wasn't very clear. My idea is to ignore whether a top-level binding
 started life as a join point, and instead optimise all top-level bindings
 the same way.

 That sounds like something we should do! Making them join points would
 still have additional advantages for code layout and possible register
 allocation. So a late "float in" pass of sorts after we are done inlining
 might still make sense.

 But your suggest changes should still reduce overhead of these calls quite
 a bit compared to what we have now.

 > These would be interesting ideas to try out. If you feel motivated, I
 could advise.

 I'm interested as I might need these optimizations for other things I'm
 working on anyway.

 I guess a good way to start would be to look into 1) starting at the
 StgToCmm code?

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