[llvm-dev] Non-relocating GC with liveness tracking

[Chuan Qiu via llvm-dev]

Thanks for reviving this.
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.

On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>
wrote:

> Returning to an ancient thread.  Sorry for the prolonged lack of response.
>
> 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.
>
> 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.
>
> Philip
>
>
> On 12/8/17 1:29 PM, Chuan Qiu via llvm-dev wrote:
>
> Hi Team,
> I'm working on a new pure functional language and I'm trying to add GC
> support for that.
>
> 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.
>
> 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.
>
> 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.
>
> 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 (
> http://lists.llvm.org/pipermail/llvm-dev/2017-August/116291.html), 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.
>
> 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?
>
> 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.
>
> Any advise will be welcome.
>
> Thanks
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181119/c8a17e29/attachment.html>