#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