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

 Replying to [comment:6 simonpj]:
 > 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.)

 I was under the impression that join points never allocate and that they
 rather re-use the closure of their enclosing scope. Also, currently full
 laziness will never float join points (or any other binding) that closes
 over local variables to top-level, so we can probably disregard heap
 overflow checks.

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