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

Chuan Qiu via llvm-dev llvm-dev at lists.llvm.org
Fri Dec 8 13:29:10 PST 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171208/8a0e796b/attachment.html>


More information about the llvm-dev mailing list