<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 08/23/2018 03:55 PM, TB Schardl
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGAvDYjiQ6sJCVdVt9Yb6WQyHNk7Zxe62MZ+9WCk93=z+1RpvA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<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" moz-do-not-send="true">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"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
</blockquote>
I have no idea what <font face="monospace, monospace">setHasOpaqueSPAdjustment(true)</font>
is or does, so I cannot give an answer to your question. Does it
ensure that %rsp can be safely changed by function calls?<br>
<br>
Demi<br>
<font face="monospace, monospace"></font>
</body>
</html>