<br><br><div class="gmail_quote">On Fri, Sep 24, 2010 at 10:44 AM, nicolas geoffray <span dir="ltr"><<a href="mailto:nicolas.geoffray@gmail.com">nicolas.geoffray@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Thanks for the heads up Chris.<div><br></div><div>Talin, how is your GC dealing with non-pointers (be it allocas or not)? What is the use-case (either in C or LLVM)?</div></blockquote><div><br></div><div>Many languages support the notion of a "value type". Value types are always passed by value, unlike reference types which are always passed by pointer. An example is the "struct" type in C#. Another example is a "tuple" type. A value type which is a local variable lives on the stack as an alloca, not on the heap. When a function is called with a value type as argument, the callee gets its own copy of the argument, rather than sharing a pointer with the caller.</div>

<div><br></div><div>Value types are represented in LLVM using structs, and may contain pointer fields which need to be traced.</div><div><br></div><div>The way that I handle non-pointer types is to generate an array of field offsets (containing the offset of each pointer field within the struct) as the metadata argument to llvm.gcroot. This meta argument is then processed in my GCStrategy, where I add the stack root offset to the offsets in the field offset array, which yields the stack offsets of the actual pointers in the call frame.</div>

<div><br></div><div>It's all pretty simple really.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div><div>Nicolas<br><br><div class="gmail_quote">

<div><div></div><div class="h5">
On Fri, Sep 24, 2010 at 7:00 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div></div><div class="h5">
<div><div></div><div>On Sep 22, 2010, at 8:52 AM, Talin wrote:<br>
> I'm moving this thread to llvm-dev in the hopes of reaching a wider audience.<br>
><br>
> This patch relaxes the restriction on llvm.gcroot so that it can work with non-pointer allocas. The only changes are to Verifier.cpp - it appears from my testing that llvm.gcroot always worked fine with non-pointer allocas, except that the verifier wouldn't allow it. I've used this patch to build an efficient stack crawler (an alternative to shadow-stack that uses only static constant data structures.)<br>



><br>
> Here's a deal: If you accept this patch, I'll write up an extensive tutorial on how to write a stack crawler like mine. (Actually, it's already written, however without this patch the tutorial doesn't make any sense.)<br>



<br>
</div></div>Hi Talin,<br>
<br>
I don't think anyone is really using the GC support, other than Nicolas in VMKit.  If he's ok with the change, I am too.  Please make sure the dox stay up to date though.<br>
<br>
-Chris<br></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br>-- Talin<br>