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

[Philip Reames via llvm-dev]

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 list
> llvm-dev at lists.llvm.org
> http://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/20181114/f0f60edb/attachment.html>