search for: llvm_gc_initialize

We are trying to start an explicit garbage collect by calling llvm_gc_collect(). We have the function declared in GCInterface.h with the following lines: #ifdef __cplusplus #define C_LINKAGE extern "C" #else #define C_LINKAGE #endif C_LINKAGE void llvm_gc_initialize(unsigned InitialHeapSize); C_LINKAGE void llvm_gc_collect(); and I can see it in the gc byte code, $ llvm-nm GC/Generational/Debug/generational.bc | egrep '(collect|initialize)' T llvm_gc_initialize t _Z22collect_between_levelsii T llvm_gc_collect d _ZZ1...

...assume I want to add a simple copying garbage collector. I write an implementation called copycollector.c (based on semispace.c) that implements the functions declared in GCInterface.h. When my frontend generates LLVM IR code for a program, it should also generate a call (early in the IR 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) {...

...gt;: >> OK, so for instance if I wanted to be able to use the GC from a C >> frontend (presumably by using llvm_gc_allocate?), do the C functions >> need this attribute as well? > > Yes. I forgot I still needed an answer to my original question. :-P So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and llvm_gc_collect (llvm_cg_walk_gcroots is provided by the Collector framework, right?) -- in those methods, how do I access the Collector object instantiated by LLVM? (It appears I do have to implement them myself, since otherwise there are unresolved symbols when I call them...

...at 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, i8* null) ; *pa = 99; %t0 = add i3...

...;m not going to answer each individually, but will instead give general guidance to help you avoid the pain points… > I somehow need to inform the garbage collection runtime (my > copycollector.c) about my variables - specifically about gc roots. > So, after I get new memory using llvm_gc_initialize, I think I > should generate an @llvm.gcroot intrinsic. This is correct. Think of the llvm.gcroot intrinsic call as an annotation on a stack variable (an alloca). Like noalias, it doesn't generate any code itself. Rather, it instructs the code generator to keep track of the locatio...

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

I'm in a group tasked with improving the GC of LLVM for a 421 project. We are having trouble getting started with the given SemiSpace collector. We found the string llvm_gc_initialize called from a single source file ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll which we tried with the following... (showing LLVM checked out from cvs a few days ago, similar output with release 1.3) $ llvm-as alloc_loop.ll $ lli alloc_loop.bc lli: Globals.cpp:81: llvm::GlobalVariable::Globa...

On Apr 20, 2008, at 6:52 PM, Gordon Henriksen wrote: > On 2008-04-20, at 21:05, Terence Parr wrote: > >> On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote: >> >>> Since the semispace heap doesn't actually work (it's an example, >>> at best), I suggest you simply copy the stack visitor into your >>> project; it's only a dozen lines of

...refcnt_dec(void *obj) { if (obj != NULL) { BlockHeader *header = header_get(obj); unsigned *count = &header->field.count; --(*count); if (*count == 0) { LINK(scan, header); /* if refcount is 0, schedule obj to be collected */ SET_POINTER(header); } } } /* llvm_gc_initialize - do nothing */ void llvm_gc_initialize(unsigned InitialHeapSize) { } /* We always want to inline the fast path, but never want to inline the * slow path. */ void *llvm_gc_allocate(unsigned Size) __attribute__((always_inline)); static void* llvm_gc_alloc_slow(unsigned Size) __attribute__((noin...

On Jul 26, 2008, at 10:32, Simon Ask Ulsnes wrote: > I forgot I still needed an answer to my original question. :-P > > So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and > llvm_gc_collect Yes. Your implementation of the llvm_gc_* functions should be compiled into a library and linked with your executable. > (llvm_cg_walk_gcroots is provided by the Collector framework, right?) An implementation of llvm_cg_walk_gcroots compatible w...

On 2008-07-23, at 11:48, Simon Ask Ulsnes wrote: > Thank you for that clarification. > >> The framework decides which Collector to use based upon the 'gc' >> attribute of a function: >> >> define void @f() gc "mygc" { >> ... >> } > > OK, so for instance if I wanted to be able to use the GC from a C > frontend (presumably by

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 > ;;

Thank you for that clarification. > The framework decides which Collector to use based upon the 'gc' > attribute of a function: > > define void @f() gc "mygc" { > ... > } OK, so for instance if I wanted to be able to use the GC from a C frontend (presumably by using llvm_gc_allocate?), do the C functions need this attribute as well? And if so, can this

On Tue, 26 Oct 2004, Tom Brown wrote: > I'm in a group tasked with improving the GC of LLVM for a 421 project. > We are having trouble getting started with the given SemiSpace > collector. > > We found the string llvm_gc_initialize called from a single source file > ./test/Regression/CodeGen/Generic/GC/alloc_loop.ll > which we tried with the following... (showing LLVM checked out from cvs a few days ago, similar > output with release 1.3) > > $ llvm-as alloc_loop.ll > $ lli alloc_loop.bc > lli: Globals.c...