#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