[LLVMdev] getting closer!

[Terence Parr]

On Apr 22, 2008, at 3:27 PM, Gordon Henriksen wrote:
> If you'd like to propose clarified language once you've wrapped your  
> head around the framework, I'd be happy to incorporate it. Most  
> ideally, submit a patch against GarbageCollection.html in http://llvm.org/svn/llvm-project/llvm/trunk/docs/ 
> .

Cool. Ok, I have already submitted some svn diffs to Chris to fix typos.

>>>>
>>>> What I was/am missing is the explicit link between types and  
>>>> variables in a GC.c file and the generated machine code.  If I  
>>>> can get that last explicit link, I'm off to the races.
>>>
>>> You mean, how do you know what sort of object you're tracing?
>>
>> I assumed that I needed to generate my object maps or at least a  
>> list of pointers for each object type.  Related to that, i have two  
>> important questions:
>>
>> 1. How do I know the offset (due to alignment/padding by LLVM) of a  
>> pointer within an object using {...} struct type?  GEP instruction  
>> gets an address, of course, but how does my C collector compute  
>> these.  Do I need to make a metadata struct and fill it with GEP  
>> instructions?  I guess that makes sense.
>
> You can use a constant expression to compute this. Specifically:
>
> i32 ptrtoint(gep %mytype* null, i32 0, i32 ??? to i32)
>
> Where ??? is the number of the field within the struct. (Could be a  
> list of indices.)

Wow!  Cool trick. I have verified that this and the next works.  BTW,  
I had no idea that that nested notation was possible! How did I miss  
that in the documentation...

>> 2. How do I know how big a struct is?  I have my gc_allocate() method
>
> Note: There's absolutely nothing special about the name  
> @llvm_gc_allocate, it's just a gentle suggestion. In fact, if you're  
> using the "model 1" heap tracing strategy, you probably want to use  
> something like this:
>
> %class.object* @alloc_object(%runtime.class* %vtable, i32 %nbytes)

an excellent idea. At the moment I am just doing structs not objects  
so that I can figure things out.

> You can again use a constant expression here. Specifically:
>
> i32 ptrtoint(gep %mytype* null, i32 1 to i32)
>
> ConstantExpr has a helper similar to sizeOf(Type*) which build this  
> expression.

I'm always using the pure text input headline generating everything  
from Java...

>>>
>>> • If you have a type forest (as in C or C++) with optional  
>>> vtables, then no such assumption is possible, and you can include  
>>> type layout information in the %metadata parameter to  
>>> @llvm.gcroot. The FrameMap type includes this data.
>>
>> Ok, so I pass it an arbitrary struct pointer and it just gives it  
>> back later for me to peruse, right?
>
> Yep! You can use any constant pointer (which means: any global  
> variable, alias, or function). For example, something like this:
>
>
[snip]

Oooooooh! man!  that is exactly what I was looking for.  hooray!   
Input/Output pairs are the best way to learn this stuff as far as I  
can tell.

I believe I have enough from this to construct a collector using the  
"shadow-stack" mechanism.  thanks so much!

"All our roots are belong to you!"

Ter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080422/333f4827/attachment.html>