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

[Philip Reames via llvm-dev]

Actually, are you possibly using "bundle" to refer to a set of arguments 
to the statepoint?  We've since introduced "operand bundles" which is 
what I assumed you meant.

On 11/25/18 6:56 PM, Philip Reames wrote:
>
> 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.
>
> Philip
>
> On 11/19/18 12:01 AM, Chuan Qiu wrote:
>> 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 <mailto: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 list
>>>     llvm-dev at lists.llvm.org  <mailto: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/20181125/d39471e5/attachment.html>