#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.)
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 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. 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