[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            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Wow, that's an impressively large effect.  Thanks -- I had no idea.  If
 you stare at the assembly code, can you guess which of your bullets is
 causing the effect here?  E.g. do we in fact end up eliminating one of the
 jump instruction?

 Your point about the stack check is a good one.

 Info tables.  Suppose a function is:
  * top level
  * not exported
  * always called with know, saturated calls

 Then it does not need either slow entry code or an info table.  So rather
 than avoid creating such functions (by not floating join points) maybe we
 should apply the optimisation uniformly to all top-level functions?

 Hmm.  What about heap checks?  If a join point `j` does heap allocations,
 where do we do the heap-overflow check?  Maybe we should absorb the heap
 allocation into the jump site (as if the code was inlined)?  That could
 avoid doing two heap checks where only one is needed. (Would only work for
 non-recursive join points.)

 Also I'm unclear about how we save live variables around a GC call at the
 start of a join point.  (On function entry we use the function's info
 table; on a case return point we use its info table.)

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