[LLVMdev] Interfacing llvm with a precise, relocating GC

[Reid Kleckner]

On Tue, Oct 29, 2013 at 1:17 PM, Sanjoy Das <sanjoy at azulsystems.com> wrote:

> Hi Talin,
>
> Thank you for your response!
>
> Since you mention that you don't implement derived pointers, I'm a
> little confused about how your approach solves the issue I brought up.
> It seems to me that unless you plan on pinning some objects, support
> for derived pointers isn't optional.  I'm not talking about derived
> pointers that the front-end introduces (which can be tracked) but the
> ones that are introduced by llvm during IR level optimizations or,
> worse, during and after instruction selection.
>
> To be sure that we're talking about the same thing, as an example,
> consider the loop (in pseudo llvm IR):
>
> for (int i = 0 to (length - 1)) {
>  total += a[i];
>  safepoint(); // This thread may be stopped here, and `a'
>               // may be relocated.
> }
>
> llvm can transform this loop to
>
> for (int *i = &a[0] to &a[length - 1]) {
>  total += *i;
>  safepoint(); // llvm has now introduced an additional
>               // derived pointer, `i'.
> }
>
> From llvm's point of view this is a valid transformation; but it ends
> up creating a new pointer the GC has to be aware of, and needs to be
> relocated in sync with a.


LLVM shouldn't do this if you're using the gcroot intrinsic.  Your example
would be:

llvm.gcroot(a) // a escapes
for (int i = 0 to length - 1) {
  total += a[i];
  safepoint() // a could be modified since it escaped
}

See, like Talin said, gcroot blocks a lot of optimization.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131029/8277ba12/attachment.html>