Yes, it's definitely OK. In the future, I think the verifier will also be changed to support non-allocas in llvm.gcroot.<div><br></div><div>Nicolas<br><br><div class="gmail_quote">On Sat, Sep 25, 2010 at 11:51 PM, Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com">viridia@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Sat, Sep 25, 2010 at 10:51 AM, nicolas geoffray <span dir="ltr"><<a href="mailto:nicolas.geoffray@gmail.com" target="_blank">nicolas.geoffray@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I didn't have unions in mind - indeed you need some kind of static information in such a case. The GC infrastructure in LLVM having so little love, I think it is good if you can improve it in any ways, as well as defining new interfaces.</blockquote>
<div><br></div></div><div>So the patch is OK then? All it does is change the verifier -- llvm.gcroot already has the ability to do this, its just that the verifier wouldn't allow it. </div><div><div></div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<br></div><div>Cheers,</div><div>Nicolas<div><div></div><div><br><br><div class="gmail_quote">On Sat, Sep 25, 2010 at 6:38 PM, Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com" target="_blank">viridia@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Sat, Sep 25, 2010 at 1:04 AM, nicolas geoffray <span dir="ltr"><<a href="mailto:nicolas.geoffray@gmail.com" target="_blank">nicolas.geoffray@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Talin,<br><br><div class="gmail_quote"><div>On Sat, Sep 25, 2010 at 4:18 AM, Talin <span dir="ltr"><<a href="mailto:viridia@gmail.com" target="_blank">viridia@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><div><br></div></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></blockquote><div><br></div></div><div>Yes.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<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></blockquote><div><br></div></div><div>Yes.</div><div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div></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> </div></div></blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div></div></div></blockquote><div><br></div></div><div>Did you think of the alternative of calling llvm.gcroot on pointers in this struct? This requires to change the verifier to support non-alloca pointers in llvm.gcroot, but it makes the solution more general and cleaner: pointers given to llvm.gcroot only point to objects in the heap.</div>
<div><br></div><div>I think that, originally, the purpose of the second argument of llvm.gcroot was to emit static type information.</div></div></blockquote><div><br></div></div><div>Let me give you a more complicated example to see why this won't work:</div>
<div><br></div><div>Imagine I have a discriminated union type, whose type declaration looks like this:</div><div><br></div><div> var x:int or String.</div><div><br></div><div>The variable 'x' can be either an integer or a reference to a string object. In LLVM assembly, this data structure is represented by the following struct:</div>
<div><br></div><div> { i1, String * }</div><div><br></div><div>The 'i1' field (the 'disciminator') is used to determine what kind of value is currently stored in the union. If it's 0, then it's an int, and the structure will be cast to { i8, int } before extracting the value. If it's 1, then it's a String pointer. The compiler does not allow access to the wrong type - if the value it 0, the language does not allow you to extract the value as a String.</div>
<div><br></div><div>Now, suppose we declare this as a local variable, so the union struct is contained within an alloca. We want to declare the String pointer as a root, but only if the discriminator is not 0. We can't determine this at compile time, instead the collector has to be smart enough to examine the union and determine whether it contains a pointer or not.</div>
<div><br></div><div>In my compiler, what I do is to generate a callback function that can trace the object. This callback function is contained within a data structure that is passed as the metadata argument to llvm.gcroot.</div>
<div><br></div><div>So my code looks like this (bit casts omitted for simplicity):</div><div><br></div><div> %int_or_string = type { i8, String * }</div><div> %x = alloca %int_or_string</div><div> call void llvm.gcroot( i8 ** x, i8* @.tracetable.int_or_string)</div>
<div><br></div><div>Where '.tracetable.int_or_string' is the static type information for the "int or string" type, containing both the field offsets and the callback function to test the value of the disciminator.</div>
<div><br></div><div>Note that if I only declared the pointer as a root, then this wouldn't work - the collector needs access to the entire data structure in order to trace the object correctly.</div><div><br></div><div>
Also, I think this is the right solution - llvm.gcroot is only responsible for the offset of the base of the alloca, not for any of it's internal structure, which is the responsibility of the compiler and the GCStrategy.</div>
<div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><font color="#888888"><div>Nicolas</div></font><div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div></div><div>It's all pretty simple really.</div><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>
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>
<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></div><br><br clear="all"><br>-- <br><font color="#888888">-- Talin<br>
</font></blockquote></div></div><br>
</blockquote></div></div><br><br clear="all"><br>-- <br><font color="#888888">-- Talin<br>
</font></blockquote></div><br></div></div></div>
</blockquote></div></div></div><br><br clear="all"><br>-- <br><font color="#888888">-- Talin<br>
</font></blockquote></div><br></div>