[GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all

[GHC]

#8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all
-------------------------------------+-------------------------------------
        Reporter:  carter            |                Owner:  carter
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.7
      Resolution:                    |             Keywords:
                                     |  callingConvention
Operating System:  Unknown/Multiple  |         Architecture:  x86_64
 Type of failure:  Runtime           |  (amd64)
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by michalt):

 * cc: simonmar, rwbarton (added)


Comment:

 There's been an interesting discussion about this in:
 https://github.com/ghc-proposals/ghc-proposals/pull/17

 If people still think this would be a good idea, I'd like to try
 things out.  But I need some help to get started. :)

 First question.
 It seems to me that there are two slightly different ideas here:

 1) using `%rsp` for managing the Haskell stack (instead of `%rbp`)

 2) using `call`/`ret`

 Is 1) really a strict requirement for 2)? IIUC we're already using
 C-stack (`%rsp`) for spilling things during register allocation.  The
 only problem I can think of is the amount of space for those return
 addresses.  Am I missing something else or is this enough to prevent
 us from using `call`/`ret`? (also, somewhat related, wouldn't using
 `call`/`ret` allow us to get rid of proc-point splitting for LLVM?)

 Second question.
 For every `CmmCall` that contains `cml_cont` we'd need to compile this
 into two instructions: `call` and `jmp <block from cm_cont>` (to jump
 over the info table that preceeds the block where we want to return
 to). But that means that the return address no longer points to the
 info table. Does anything else depend on this? Is there some easy way
 to check that?

 Third question.
 How could this work in LLVM backend? I don't think LLVM even allows
 direct manipulation of the stack pointer. Also, even if we could
 manipulate it, I wouldn't be surprised if LLVM wanted to move things
 around the stack, which again sounds pretty problematic (for, e.g.,
 GC)

 PS. CCing simonmar and rwbarton since they were the main contributors
 to the linked GHC proposal. (hope you don't mind!)

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