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

陳韋任 via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 15 09:33:19 PST 2017


I remember Haskell GHC using LLVM as its backend. Haskell is pure
functional language also. A little google search shows it supports garbage
collection, too. Looking into GHC's implementation might be help.

2017-12-09 5:29 GMT+08:00 Chuan Qiu via llvm-dev <llvm-dev at lists.llvm.org>:

> 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
>
>


-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171216/974ec207/attachment.html>


More information about the llvm-dev mailing list