search for: gcreading

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/writing to is. Also

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

Ok, here's the new patch. (Please tell me if I shouldn't mail patches directly on the mailing list.) While I was editing LowerGC.cpp I made a little test (not part of this patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer directly instead and transforms it into an alloca. The idea is the

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

.... 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 me...

On Wed, 21 Jul 2004, Chris Lattner wrote: > > Yes, this makes a tremendous amount of sense. Do you think you could > prepare some patches to make this happen? If you have any questions, feel > free to ask :) Ok, a patch[1] is attached. I didn't care to coerce the offset, since I assume that it is an uint, but maybe I should? Hopefully I've understood the llvm source

Gordon Henriksen wrote: > Hi Mark, > > I don't think anyone will dispute that it's easier to hack up a shadow > stack (or plug into a conservative collector) to get up and running > with GC. That is absolutely the route to go if portability trumps > performance. Why? LLVM is all about portability AND performance. > > If you review the mailing list history,

On Apr 28, 2008, at 10:50, Jonathan S. Shapiro wrote: > 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

On Feb 27, 2009, at 12:56, Mark Shannon wrote: > Gordon Henriksen wrote: > >> The ultimate endgoal is to support schemes with still-lower >> execution overhead. The next step for LLVM GC would be elimination >> of the reload penalty for using GC intrinsics with a copying >> collector. This, again, requires that the code generator perform >> bookkeeping

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,

I've written a reference-counting garbage collector for LLVM, but I'm still unclear on a few things. 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 ;; it, to indicate that the value is no longer live. store %Object* null, %Object** %X ... How exactly does

Gordon Henriksen wrote: > > The "runtime interface" is a historical artifact. LLVM does not impose > a runtime library on its users. I wouldn't have a problem deleting all > mention of it, since LLVM does not impose a contract on the runtime. > Excellent, I found it somewhat unhelpful! >> The semantics of llvm.gcroot are vague: >> "At

Hi everyone, We seem to have allowed our documented target-independent intrinsics to acquire a somewhat-haphazard naming system, and I think we should standardize on one convention. All of the intrinsics have 'llvm.' as a prefix, and some also have some additional prefix 'llvm.dbg.', 'llvm.eh.', 'llvm.experimental.', etc., but after that we lose consistency. When

Hi Talin, Thanks for the feedback. My comments inline. On 2009-03-05, at 16:01, Talin wrote: > 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

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

LLVMers, Attached for your review: basic infrastructure for efficient garbage collectors. Only enough information is currently gathered to support the runtime I'm working with, and -print-gc is currently the only consumer of this information. All collector policies are presently controlled by constants. There are no regressions (on darwin-i686) if the feature is left disabled. If