<div dir="ltr"><div dir="ltr"><a href="https://github.com/eagleonhill/qlang-llvm/commit/e360bc7cd937a3c229b6f5fec3c06f961ab47c51">https://github.com/eagleonhill/qlang-llvm/commit/e360bc7cd937a3c229b6f5fec3c06f961ab47c51</a> This is the patch in CodeGen. Actually I completely forgot I did that..</div><div dir="ltr"><br></div><div>The change in GCRootPass is not done in the LLVM fork and have some coupling with my frontend, so it's not ready to publish yet.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 25, 2018 at 6:57 PM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</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">
<p>Actually, are you possibly using "bundle" to refer to a set of
arguments to the statepoint? We've since introduced "operand
bundles" which is what I assumed you meant. <br>
</p>
<div class="m_-7124708051477784099moz-cite-prefix">On 11/25/18 6:56 PM, Philip Reames
wrote:<br>
</div>
<blockquote type="cite">
<p>This sounds like an incomplete description since codegen would
have no knowledge of the new bundle type and discard them.
Would you be willing to share your patches? I'd be curious to
see there approach you took, maybe there's something analogous
we can do upstream.</p>
<p>Philip<br>
</p>
<div class="m_-7124708051477784099moz-cite-prefix">On 11/19/18 12:01 AM, Chuan Qiu
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Thanks for reviving this.</div>
<div dir="ltr">I completely forgot the details but I resolved
this problem. Looking though the code, seems I
forked RewriteStatepointsForGC pass, and change it to adding
'gc-livevars' bundle to the call/invoke inst after finding
the livevars, instead of changing it to StatepointCall
intrinsic.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Nov 14, 2018 at 11:48 AM Philip Reames
<<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</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">
<p>Returning to an ancient thread. Sorry for the
prolonged lack of response.</p>
<p>gc.statepoint is supported and actively developed. The
only production usage of LLVM's GC support I'm aware of
is using gc.statepoint. I recommend you use
gc.statepoint, not gcroot.</p>
<p>I recently made a set of documentation edits which may
provide some useful guidance for your non-relocating
collector design. I'd be curious to know what you've
settled on and what progress you've made.</p>
<p>Philip<br>
</p>
<p><br>
</p>
<div class="m_-7124708051477784099m_-5545791189006271620moz-cite-prefix">On
12/8/17 1:29 PM, Chuan Qiu via llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Team,
<div>I'm working on a new pure functional language and
I'm trying to add GC support for that.</div>
<div><br>
</div>
<div>Because all vars are immutable, the IR that my
frontend generates are all register based, i.e. no
alloca, and no readmem, writemem unless
accessing/constructing structs. </div>
<div><br>
</div>
<div>If I use the traditional GC with gcroot
intrinsic, it will need to emit more code for
liveness tracking, storing the IR values into the
gcroot, which seems convoluted. </div>
<div><br>
</div>
<div>I found using stack map / statepoints very
plausible here, because it only needs all live vars
without saving it to a corresponding gcroot, and can
track liveness at every call point.</div>
<div><br>
</div>
<div>However, this seems still marked as experimental,
and doesn't support exception handling (which is a
requirement for my language). And because my
language uses return barriar (<a href="http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html</a>),
I'm already using a new intrinsic that returns a
token type for calls so I can have multiple return
paths that retrieves the actual result, and
currently it doesn't work with gc.statepoint.</div>
<div><br>
</div>
<div>I wanna check the status of statepoint GC: Is it
still actively developed? is there any plan to fix
the exception handling path? Or should I continue to
use the gcroot intrinsic? Change my new multi-return
intrinsic to support statepoint?</div>
<div><br>
</div>
<div>I'm also thinking using a non-relocating GC with
stackmap because relocating is currently optional
for me: all live roots are passed to call site as
operand bundle, so codegen can emit the stack map,
and my new intrinsic for multiple return paths can
also work with that.</div>
<div><br>
</div>
<div>Any advise will be welcome.</div>
<div><br>
Thanks</div>
</div>
<br>
<fieldset class="m_-7124708051477784099m_-5545791189006271620mimeAttachmentHeader"></fieldset>
<pre class="m_-7124708051477784099m_-5545791189006271620moz-quote-pre">_______________________________________________
LLVM Developers mailing list
<a class="m_-7124708051477784099m_-5545791189006271620moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-7124708051477784099m_-5545791189006271620moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</blockquote></div>