similar to: [LLVMdev] 2.2 garbage collector questions

thomas weidner wrote: > Hello, > > i want to implement a common lisp subset using llvm for fun. Out of curiousity, for which CL implementation is this targeted? sbcl? Or something you're rolling? The reason why I ask is that I expressed an outrageous opinion at Supercomputing back in November, to wit, that CL is probably the best language suited for today's multicore

Scott Michel <scottm <at> rushg.aero.org> writes: > Out of curiousity, for which CL implementation is this targeted? sbcl? > Or something you're rolling? I wanted to roll out my own lisp, and maybe use some library code from existing lisps (think of loop or format). Adding an LLVM backend to an existing lisp implementation is a nice idea, but currently not planned. >

thomas weidner wrote: >>The reason why I ask is that I expressed an outrageous opinion at >>Supercomputing back in November, to wit, that CL is probably the best >>language suited for today's multicore problems... but I don't have the >>time to hack one of the current implementations to proove the point. > > > interesting, what makes lisp superior in this

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,

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,

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

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

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

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

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

Hi, I realise this might be a bit controversial ;) Suppose I am writing a VM (such as VMKit), or a VM toolkit, and I want to add a generational GC. If I want to use the llvm.gcwrite intrinsic for my write barrier then I need to write a GC and then implement for each and *every* backend the gcwrite intrinsic for my write barrier. Now, if I don't use the intrinsic, I need to write my write

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. If you review the mailing list history, I think you'll also find that developers who do care about performance have been disappointed with the impact

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

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

Scott Michel wrote: > thomas weidner wrote: > >>>The reason why I ask is that I expressed an outrageous opinion at >>>Supercomputing back in November, to wit, that CL is probably the best >>>language suited for today's multicore problems... but I don't have the >>>time to hack one of the current implementations to proove the point. >>

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

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

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

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