llvm dev - Aug 2018 - LLVM and heap-allocated thread stacks

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180821/0b1c271f/attachment-0001.html>

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> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180823/f3ae64a6/attachment.html>

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>