[GHC] #8048: Register spilling produces ineffecient/highly contending code

[GHC]

#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