<div dir="ltr">Speaking as a bystander just trying to understand the problem: Are you looking for a way to ensure that "<font face="monospace, monospace">setHasOpaqueSPAdjustment(true)</font>" is executed on appropriate MachineFrameInfo objects during CodeGen for GHC and Go?  Or do you need something more than that?<div><br></div><div>Cheers,</div><div>TB</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 23, 2018 at 2:08 PM Demi M. Obenour via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  

    
  
  <div text="#000000" bgcolor="#FFFFFF">
    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.<br>
    <br>
    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 *<i>any call into the RTS may then change the
      stack pointer*.</i>  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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    Sincerely,<br>
    <br>
    Demi Obenour<br>
  </div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>