[llvm-dev] (no subject)

[Philip Reames via llvm-dev]

The general assumption is that you use RS4GC to lower the abstract 
machine model.

I think there's IRBuilder support.  If not, patches welcome!

Philip

On 10/21/19 12:06 AM, Yafei Liu wrote:
> Hi Philip, are there any C++ APIs to generate the llvm 
> statepoint instructions? I didn't found APIs similar to how to 
> generate gcroot instructions.
>
> On Mon, Oct 21, 2019 at 2:03 PM Yafei Liu <yfliu at mobvoi.com 
> <mailto:yfliu at mobvoi.com>> wrote:
>
>     Thanks Philip,  I'll keep investigating.
>
>     On Mon, Oct 21, 2019 at 9:52 AM Philip Reames
>     <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>         Correct, with a couple of nit picks.
>
>         Relocation isn't an optimization the collector performs.  It's
>         a key primitive the collector is built upon.  Being unable to
>         relocate is not an allowed state.  (i.e. pinning can't be
>         required by the compiler)
>
>         When you talk about variables, that's true for the *source*
>         language and for the *abstract* machine before lowering. 
>         After lowering from the abstract machine, relocations are
>         represented in the IR explicitly as an entirely new set of defs.
>
>         Philip
>
>         On 10/20/19 6:40 PM, Yafei Liu wrote:
>>         Correct me if I'm wrong:
>>         Relocation in this conversation "relocation" means GC trying
>>         to move objects in the heap for optimization (make the data
>>         more impact for bigger room for example), this move is
>>         invisible to a programmer, and if a compiler support to
>>         " relocate objects directly reachable from running code", a
>>         variable (Foo foo) may points to a different address after a
>>         GC happens, while a programmer could still use the name foo
>>         in the code as if nothing happened.
>>
>>         On Sun, Oct 20, 2019 at 4:35 AM Philip Reames via llvm-dev
>>         <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>>             Exactly this.  (As the person who wrote the line in
>>             question.)
>>
>>             On 10/18/19 8:50 AM, Hiroshi Yamauchi via llvm-dev wrote:
>>>             I think it's referring to a "moving" garbage collector
>>>             (as opposed to a "non-moving" garbage collector that
>>>             never moves/relocates objects.) The difference is that
>>>             for a moving one, all pointers need to be tracked and
>>>             potentially updated, whereas for a non-moving one, it's
>>>             sufficient that at least one pointer to a live object is
>>>             seen (when there may be other pointers to the same
>>>             object elsewhere) for correctness.
>>>
>>>             On Fri, Oct 18, 2019 at 2:12 AM Yafei Liu via llvm-dev
>>>             <llvm-dev at lists.llvm.org
>>>             <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>
>>>                 Hi all,
>>>
>>>                 I'm investigating on integrating a gc to my llvm
>>>                 project, and when I read this document
>>>                 <http://llvm.org/docs/Statepoints.html>, one
>>>                 sentence confused me:
>>>
>>>                     However, for a collector which wishes to
>>>                     relocate objects directly reachable from running
>>>                     code, a higher standard is required.
>>>
>>>                 I don't understand what the move "relocate objects
>>>                 directly reachable from running code" trying to do.
>>>
>>>                 For my information, the concept "relocate" means the
>>>                 gc pointer refereed to a new location of an object,
>>>                 for example:
>>>
>>>                 in Java:
>>>
>>>                 |Foo foo = new Foo(); foo = new Foo(); // ---> a
>>>                 relocation happens |
>>>
>>>                 So can anyone explain what the "relocate objects
>>>                 directly reachable from running code" trying to do?
>>>
>>>                 _______________________________________________
>>>                 LLVM Developers mailing list
>>>                 llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>>                 https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>>             _______________________________________________
>>>             LLVM Developers mailing list
>>>             llvm-dev at lists.llvm.org  <mailto:llvm-dev at lists.llvm.org>
>>>             https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>             _______________________________________________
>>             LLVM Developers mailing list
>>             llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>             https://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/20191021/f52242ac/attachment.html>