#8048: Register spilling produces ineffecient/highly contending code -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: register Operating System: Unknown/Multiple | allocator spill Type of failure: Runtime | Architecture: Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by carter): Looking at this, it looks like the real issue is the lack of an analogue of the llvm mem2reg optimization for the ghc stack I think... (ie what we have here is one basic block is pushing args onto the stack, then we're funcalling to another basic block that is unloading them again) (and llvm's mem2reg can't do it because GHC manages its own stack in a way llvm doesn't understand) https://github.com/mlite/HsLlvm/blob/master/src/Llvm/Pass/Mem2Reg.hs is a implementation of mem2reg using hoopl, for the llvm ir, might be worth figuring out how to make that work for cmm. (what follows is me sketching out an idea, though I or someone else will have to do some experimentation to see if it helps ) naively: what I '''think''' is going on is we have a few different basic blocks as CMM functions going on in the test code for the ```spill``` function, and we're moving between these blocks using general function calls, when we actually went to ''' "fuse" ''' the blocks together so that we don't have this busy work of doing the trivial spill to stack only to immediately unspill again. ok, now that i've thought about it out loud, might be easier to do this optimization before we go to CMM, because then we dont have to invert the spill / unspill code -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8048#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler