search for: gc_alloc

...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. 2. How do I know how big a struct is? I have my gc_allocate() method but I have no idea how big the struct will be; i see now sizeof. Alignment makes it unclear how big something is; it's >= size of elements like i32 but how much bigger than packed struct is it? I.e., %struct.A = type {i32 x, [10 x i32]*} define void @foo() gc "shad...

Thanks for the example code. Its gives a good idea how the shadow stack works. But I have another question. Using the shadow stack is a nice and simple way to implement GC, but it might have a large runtime overhead per function call. Is there another way to preserve garbage specific information (gcroots) through the llvm optimizer and native code generator? This information could be used to

...tions? 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.) > 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...

On Apr 21, 2008, at 20:09, Terence Parr wrote: > Ok, I *might* be getting this from the assembly code. ... From > that, it will push/pop in functions? If so, that's easy enough. :) Yup! Sounds like you've got it. > 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

...f 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.obj...

...machine code. If I can get that last explicit link, I'm off to the races. Anybody? My IR doesn't seem to have any roots, even though I've allocated an int and declared a ptr on the stack. declare void @llvm.gcroot(i8 **, i8*) declare void @llvm_gc_collect() declare i32* @llvm_gc_allocate(i32) declare void @llvm_gc_initialize(i32) define void @foo() gc "shadow-stack" { ; int *pa = malloc(sizeof(int)); %a = call i32* @llvm_gc_allocate(i32 4) %pa = alloca i32* store i32* %a, i32** %pa %c = bitcast i32** %pa to i8** call void @llvm.gcroot(i8** %c...