search for: objptr

I'm allocating { i8*, i32 } on the stack, and would like to add this as a GC root, but I'm having trouble figuring this out. This works as expected: declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) define i8* @bar(i8* %x) gc "shadow-stack" { entry: %objptr = alloca i8* call void @llvm.gcroot(i8** %objptr, i8* null) store i8* %x, i8** %objptr %v = load i8*, i8** %objptr ret i8* %v } However, when I have this: define { i8*, i32 } @foo({ i8*, i32 } %x) gc "shadow-stack" { entry: %objptr = alloca { i8*, i32 } %rootptr = bitcast {...

...i8*, i32 } on the stack, and would like to add this as a > GC root, but I'm having trouble figuring this out. > > This works as expected: > > declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) > > define i8* @bar(i8* %x) gc "shadow-stack" { > entry: > %objptr = alloca i8* > call void @llvm.gcroot(i8** %objptr, i8* null) > store i8* %x, i8** %objptr > %v = load i8*, i8** %objptr > ret i8* %v > } > > However, when I have this: > > define { i8*, i32 } @foo({ i8*, i32 } %x) gc "shadow-stack" { > entry: >...

On Mon, 27 Feb 2006, Sandro Magi wrote: > Couple of questions: Ok, it's been a long while since I've worked on the GC stuff, but I'll try to help :) > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > I haven't seen an adequate explanation of these, but I'm guessing: > void *V: value being written to the field > void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr > upon entry to llvm_gc_write) > void **FieldPtr: address of the fiel...

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The cu...

On 2/27/06, Chris Lattner <sabre at nondot.org> wrote: > > 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > > > I haven't seen an adequate explanation of these, but I'm guessing: > > void *V: value being written to the field > > void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr > > upon entry to llvm_gc_write) > > void *...

On Sun, 2008-04-27 at 22:34 -0400, Gordon Henriksen wrote: > On 2008-04-27, at 21:29, Lane Schwartz wrote: > > Since this is a simple copying collector, the functions llvm_gc_read > > and llvm_gc_write won't really do much: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return > > *FieldPtr; } > > void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > > { *FieldPtr = V; } > > You can just emit loads and stores directly if your read/write > barriers do nothing. Also, there's nothing special about the...

...code) to llvm_gc_initialize. This function uses the system calloc to allocate two big blocks of memory, then stores pointers to that memory in static variables. Since this is a simple copying collector, the functions llvm_gc_read and llvm_gc_write won't really do much: void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return *FieldPtr; } void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) { *FieldPtr = V; } There is also a function called llvm_gc_allocate. Now, instead of using alloca or malloc, my frontend generates a call to llvm_gc_allocate. Up to this point I feel pretty good abo...

Couple of questions: 1. void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) I haven't seen an adequate explanation of these, but I'm guessing: void *V: value being written to the field void *ObjPtr: current value of the field (ie. ObjPtr == *FieldPtr upon entry to llvm_gc_write) void **FieldPtr: address of the field being written 2. The cu...

...use any names and prototypes it likes to provide this functionality. A bump- ptr allocator might easily inline part of its allocation routine. > Since this is a simple copying collector, the functions llvm_gc_read > and llvm_gc_write won't really do much: > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return > *FieldPtr; } > void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) > { *FieldPtr = V; } You can just emit loads and stores directly if your read/write barriers do nothing. Also, there's nothing special about the llvm_gc_read or llvm_gc_write...

...etter to take two pointers in instead of a pointer and offset. This allows the front-end to emit target-generic code instead of target-specific code (where it would have to know the offset to the field). To be more specific, llvm_gc_read should look like this by default: void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return *FieldPtr; } Also, please don't forget to update docs/GarbageCollection.html and LangRef.html Thanks for the help, sorry I didn't mention this before. :) -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > return *FieldPtr; > > } > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > cases? For the field pointer, one could use the getelementptr instruction: %pairty = { sbyte, sbyte, int* } %pairPtr = ... %fieldptr = gete...

Ok, that makes sense :). , Tobias On Wed, 21 Jul 2004, Chris Lattner wrote: > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > return *FieldPtr; > > > } > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > cases? > > For the field pointer, one could use the getelementptr instruction: > > %pairty = { sbyte, sbyte,...

...instead of > a pointer and offset. This allows the front-end to emit target-generic > code instead of target-specific code (where it would have to know the > offset to the field). To be more specific, llvm_gc_read should look like > this by default: > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > return *FieldPtr; > } Hm, but doesn't FieldPtr need to be calculated target-specific in those cases? My thoughts was that it's better to just have one pointer to the heap, and reference fields by offset, rather than alloca'ing memory for each FieldPtr nee...

...es how the gcroots are implemented. , Tobias On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Ok, that makes sense :). > , Tobias > > On Wed, 21 Jul 2004, Chris Lattner wrote: > > > On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > > > void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { > > > > return *FieldPtr; > > > > } > > > > > > Hm, but doesn't FieldPtr need to be calculated target-specific in those > > > cases? > > > > For the field pointer, one could use the getelementptr instruction: &...

...> On Sun, 2008-04-27 at 22:34 -0400, Gordon Henriksen wrote: >> On 2008-04-27, at 21:29, Lane Schwartz wrote: >>> Since this is a simple copying collector, the functions >>> llvm_gc_read and llvm_gc_write won't really do much: >>> void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return >>> *FieldPtr; } >>> void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) >>> { *FieldPtr = V; } >> >> You can just emit loads and stores directly if your read/write >> barriers do nothing. Also, there's nothing...

...refs */ for (; head != NULL; head = head->field.next) { free(head); /* FIXME: this should also decrement the ref count of all pointers within * head, which places them in the 'scan' list. */ } } } /* We use no read barrier */ void *llvm_gc_read(void *ObjPtr, void **FieldPtr) { return *FieldPtr; } /* write barrier to increment and decrement refcounts */ void llvm_gc_write(void *V, void *ObjPtr, void **FieldPtr) { if (ObjPtr != V) { /* skip all this work if simply resetting the field */ void *obj = *FieldPtr; refcnt_dec(obj); *FieldPtr =...

Again, sorry for the delay. :( On Thu, 9 Mar 2006, Sandro Magi wrote: > I've written a reference-counting garbage collector for LLVM, but I'm > still unclear on a few things. Cool! > The following piece of code that appears on > http://llvm.cs.uiuc.edu/docs/GarbageCollection.html is unclear: > > ;; As the pointer goes out of scope, store a null value into > ;;

...pc = <value optimized out> instructionCount = 2 expandNestList = 0x0 checkInterp = 0 cleanup = <value optimized out> objResultPtr = 0xb7dd9a54 result = <value optimized out> #35 0xb7ded791 in TclCompEvalObj (interp=0x80563a0, objPtr=0x91ff7c0, invoker=0x0, word=0) at /build/buildd/tcl8.5-8.5.7/unix/../generic/tclExecute.c:1474 codePtr = 0x923da08 result = <value optimized out> ---Type <return> to continue, or q <return> to quit--- namespacePtr = <value optimized out> #36...

Hi Terence, I think you're getting hung up on the details of the shadow stack collector. The shadow stack is a GC that is possible within this framework, but of course could be implemented without any special support. Its presence is more misleading than anything else. Taking a step back, the concepts are: llvm.gcroot instructs the code generator --> My GC needs to be able to

Hi Mike, hope you are doing well with the llvm gcjx backend. I am currently writing an llvm backend for a C like language for tracing (like D in dtrace). I am very interested in this area. Do you currently put your work in a repository? (maybe as Tom suggested gcjx.sf.net would be an easy start - since it would not require gcc committer status). I am keen on getting LLVM support for gcj. Maybe we