[llvm-dev] LLVM and heap-allocated thread stacks

[Demi M. Obenour via llvm-dev]

On 08/23/2018 03:55 PM, TB Schardl wrote:
> Speaking as a bystander just trying to understand the problem: Are you
> looking for a way to ensure that "setHasOpaqueSPAdjustment(true)" is
> executed on appropriate MachineFrameInfo objects during CodeGen for
> GHC and Go?  Or do you need something more than that?
>
> Cheers,
> TB
>
> On Thu, Aug 23, 2018 at 2:08 PM Demi M. Obenour via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     In some language implementations, such as the Glasgow Haskell
>     Compiler (GHC) and the reference implementation of Go, a thread’s
>     stack is allocated as a data structure on the garbage-collected
>     heap.  The garbage collector is free to move this data structure
>     whenever it is invoked.
>
>     Currently, GHC’s LLVM backend does not use the C stack.  However,
>     there have been discussions about whether using the C stack could
>     lead to a performance gain.  I think it could.  The elephant in
>     the room, however, is that */any call into the RTS may then change
>     the stack pointer*./  LLVM presumably has no support for this. 
>     Without such support, however, GHC must spill all locals to memory
>     at every call into the RTS.  It seems to me that this is why GHC
>     cannot transform its output into SSA form: GHC must reify its stack.
>
>     It would be nice (both for GHC and for llgo) if LLVM could be made
>     to treat the stack pointer as a volatile register that may be
>     changed by any function call.  In this model, the stack pointer
>     needs to be treated the same as any other GC’d object — stack maps
>     need to be emitted for it, and the RTS is allowed to relocate it.
>
>     Would this be practical?  If so, it would be a major boon to the
>     implementation of lightweight threading in languages that compile
>     to LLVM IR.
>
>     Sincerely,
>
>     Demi Obenour
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
I have no idea what setHasOpaqueSPAdjustment(true) is or does, so I
cannot give an answer to your question.  Does it ensure that %rsp can be
safely changed by function calls?

Demi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180823/ef113747/attachment.html>