<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">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_-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_-5545791189006271620mimeAttachmentHeader"></fieldset>
<pre class="m_-5545791189006271620moz-quote-pre">_______________________________________________
LLVM Developers mailing list
<a class="m_-5545791189006271620moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-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>