<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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="moz-cite-prefix">On 11/19/18 12:01 AM, Chuan Qiu wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAARSEjm7cgFReSGzCi3+WHCHszXFL0eKxuTd1F8TmKtB9bEMUw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>