search for: gcread

Hi, I'm thinking out loud, please give me some feedback. Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are implemented as: llvm.gcread(sbyte** object, uint offset) llvm.gcwrite(sbyte* data, sbyte** object, uint offset) Where you also have the offset into the object. In this way the GC would know where the header of the object we are reading/writ...

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > > Not currently. In the future this will definitely be improved. In > > particular, when the code generators are enhanced to provide more accurate > > mapping information for GC pointers (e.g. which registers contain > > pointers), we can do this. This is in the long term plans, but I suspect > > that performance will

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

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 = getelementptr

.../fpcmp/Debug ? llvm/utils/fpcmp/Depend Index: llvm/docs/GarbageCollection.html =================================================================== RCS file: /var/cvs/llvm/llvm/docs/GarbageCollection.html,v retrieving revision 1.6 diff -r1.6 GarbageCollection.html 237,238c237,238 < sbyte *%llvm.gcread(sbyte **)<br> < void %llvm.gcwrite(sbyte*, sbyte**) --- > sbyte *%llvm.gcread(sbyte *, sbyte **)<br> > void %llvm.gcwrite(sbyte*, sbyte*, sbyte**) 253c253,255 < second has the same semantics as a non-volatile LLVM store. At code generation --- > second has the same...

On Wed, 21 Jul 2004, Tobias Nurmiranta wrote: > > Hi, I'm thinking out loud, please give me some feedback. > > Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are > implemented as: > > llvm.gcread(sbyte** object, uint offset) > llvm.gcwrite(sbyte* data, sbyte** object, uint offset) > > Where you also have the offset into the object. In this way the GC would > know where the header...

.... how are collectors supposed to find all living objects? there is llvm.gcroot for marking objects on the stack,but how do collectors crawl heap objects? I did not see a way to provide custom mark functions. Are collectors supposed to rely on the type informations provided by llvm? 2. what about gcreading and gcwriting objects of a different type than i8*? 3. No Intrinsic for allocating gc memory? 4. When passing a gc managed pointer to a c function,how should that function access the pointer? directly? there seem to be functions for that in the runtime/ source directory,but it also seems to be...

...utput ? llvm/utils/fpcmp/Debug ? llvm/utils/fpcmp/Depend Index: llvm/lib/Transforms/Scalar/LowerGC.cpp =================================================================== RCS file: /var/cvs/llvm/llvm/lib/Transforms/Scalar/LowerGC.cpp,v retrieving revision 1.4 diff -r1.4 LowerGC.cpp 112c112 < GCRead = M.getOrInsertFunction("llvm_gc_read", VoidPtr, VoidPtrPtr, 0); --- > GCRead = M.getOrInsertFunction("llvm_gc_read", VoidPtr, VoidPtrPtr, Type::UIntTy, 0); 115c115 < VoidPtr, VoidPtrPtr, 0); --- >...

...gt; I'm not sure where such vociferous concern on this subject arises. All > the extant collector plugins I'm aware of operate in conjunction with > the target-independent framework and require exactly zero code within > each target backend. No collector plugins actually use gcread/gcwrite, since there are no generational collectors for llvm (as yet). According to the documentation http://llvm.org/docs/GarbageCollection.html#runtime The GC interface is "a work in progress" The semantics of llvm.gcroot are vague: "At compile-time, the code generator generate...

...t they should be trivially > inlined? This would allow us to debug things without imposing > performance penalties on the simple implementation. > > Actually, I can see wanting to inline these even in barrier-oriented > GC implementations... Indeed so! If you do use the @llvm.gcread and @llvm.gcwrite intrinsics (not to be confused with the above functions), they will be transparently converted to simple loads and stores, so there's “no cost” to using them. As the implementation matures, an llc plugin can trivially substitute a write barrier using the performCustomL...

...where such vociferous concern on this subject arises. >> All the extant collector plugins I'm aware of operate in >> conjunction with the target-independent framework and require >> exactly zero code within each target backend. > > No collector plugins actually use gcread/gcwrite, since there are > no generational collectors for llvm (as yet). > > According to the documentation > http://llvm.org/docs/GarbageCollection.html#runtime > The GC interface is "a work in progress" The "runtime interface" is a historical artifact. LLVM...

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

Browsing http://llvm.org/releases/2.5/docs/GarbageCollection.html#ocaml I stumbled across the sentence "...The ocaml collector does not use read or write barriers, so the user program may use load and store instead of llvm.gcread and llvm.gcwrite..." Which I believe is wrong as the ocaml collector does indeed use a write barrier (caml_modify). But maybe I misunderstood? Thanks, Benedikt Grundmann -- Calvin: I try to make everyone's day a little more surreal. (From Calvin & Hobbes)

...value into ;; it, to indicate that the value is no longer live. store %Object* null, %Object** %X ... How exactly does this indicate X is no longer live? Is this internal code-generator logic/magic? The problem I'm currently unsure of, is how roots would affect refcounts. Should the gcread/gcwrite not be used with stack refs, etc? 1. If root refs are NOT included in the count, then objects of refcount 0 must be tracked in a list of scheduled deletions, but will be continually deferred until the root goes out of scope (the deletion list is filtered during a collection by the roots ca...

...bout all my negative comments, but I would like to implement a generational collector for llvm, but I cannot do so in a portable way. So, here is a suggestion: Call the GC 'intrinsics' something else, "extinsics"?, and provide low-level intrinsics so that the GC calls, gcroot, gcread and gcwrite can be converted to GC-free LLVM code in a GC-lowering pass. IR+GC -> | GC Lowering pass | -> IR Rather than than the current. IR+GC -> | Backend lowering pass(es) | -> SelectionDAG Read and write barriers can already be written in llvm-IR. It is the marking of roots th...

...(3)). Thoughts? Although this is somewhat subjective, here's our current set of intrinsics with multiple words (or acronyms) by these categories. I'm excluding here externally-defined terms (e.g. llvm.va_start): No separators (except for the initial namespace prefix): @llvm.gcroot @llvm.gcread @llvm.gcwrite @llvm.experimental.stackmap @llvm.experimental.patchpoint @llvm.experimental.gc.statepoint @llvm.returnaddress @llvm.frameaddress @llvm.localescape @llvm.localrecover @llvm.stacksave @llvm.stackrestore @llvm.pcmarker @llvm.readcyclecounter @llvm.bitreverse @llvm.eh.begincatch...

...e any > constraint on the values that the object pointer and the derived > pointer can take? There is no constraint on the relationship between the object and derived pointer parameters except as the plugin requires. I've made this explicit. There is currently no benefit to using gcread/gcwrite vs. coding in the barrier up front. > In particular, I am thinking about the case where you have an > object, such as an ArrayList, in which there are two separate non- > contiguous allocations: A fixed-length "header" part, and a variable- > length "tail&q...

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 current semispace collector includes

I'm re-re-reading the "Accurate Garbage Collection with LLVM", and I'm realizing that there are some parts of this document I find confusing. 1) I think that the term 'stack map' should be defined more precisely. For example, in one place it says "LVM automatically computes a stack map", and elsewhere it says "The compiler plugin is responsible for

..." after calls? [2*] • " before returning? [4] • Pad safe points with noops to accommodate a patch? To how many bytes? [4a] • Allow roots in registers? Otherwise force roots into stack slots at safe points [2]. And additionally provide callbacks to: • Custom lower gcread/gcwrite intrinsics [5,6]. Otherwise replace with plain load/store [2,3*]. • Custom lower gcroot intrinsics [3*]. Otherwise leave for the code generator [2*]. • Introduce code at safe points [4b]. • Print assembly for per-function metadata. • Print assembly for whole-module metadata...