Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Garbage collection questions"
2006 Feb 27
0
[LLVMdev] Garbage collection questions
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
2008 Apr 28
3
[LLVMdev] getting started with IR needing GC
On Mon, Apr 21, 2008 at 8:13 PM, Gordon Henriksen
<gordonhenriksen at mac.com> wrote:
>
> 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
2008 Apr 28
0
[LLVMdev] getting started with IR needing GC
On 2008-04-27, at 21:29, Lane Schwartz wrote:
> Hi guys,
Hi Lane!
This is a lot of questions. I'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
2004 Jul 21
0
[LLVMdev] GC questions.
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
2004 Jul 21
2
[LLVMdev] GC questions.
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
2006 Feb 27
1
[LLVMdev] Garbage collection questions
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)
2006 Feb 27
0
[LLVMdev] Garbage collection questions
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
2008 Apr 28
2
[LLVMdev] getting started with IR needing GC
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
2004 Jul 22
2
[LLVMdev] GC questions.
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
2004 Jul 21
2
[LLVMdev] GC questions.
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
2006 Mar 14
3
[LLVMdev] Re: Garbage collection questions
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
> ;;
2008 Apr 21
2
[LLVMdev] getting started with IR needing GC
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
2006 Mar 14
0
[LLVMdev] Re: Garbage collection questions
On 3/14/06, Chris Lattner <sabre at nondot.org> wrote:
>
> > How exactly does this indicate X is no longer live? Is this internal
> > code-generator logic/magic?
>
> No, this just prevents the GC from accidentally thinking that *X is live
> through that pointer. The collector cannot distinguish between
> pointers that are out of scope from those that aren't,
2008 Apr 22
0
[LLVMdev] getting started with IR needing GC
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
2004 Jul 21
0
[LLVMdev] GC questions.
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
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> [1] I'm kind of newbie of cvs, but I did:
> "cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm diff llvm > gcpatch"
That patch is well formed. You did exactly the right thing. :)
> 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?
2004 Jul 21
0
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Chris Lattner wrote:
> On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
>
> This will work, but it would be better 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
2008 Apr 28
0
[LLVMdev] getting started with IR needing GC
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
2007 Sep 04
2
[LLVMdev] Garbage Collection Roots
On Sep 2, 2007 5:31 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote:
> Hi Talin,
>
> On Sep 2, 2007, at 04:54, Talin wrote:
>
> > I've been looking through the documentation (http://llvm.org/docs/
> > GarbageCollection.html) on how to implement a garbage collector for
> > LLVM and there's a couple of things that I don't quite understand.
>
2010 Mar 25
1
[LLVMdev] Garbage Collection
Hello,
I want to add garbage collection support to a compiler with a llvm
backend, using the shadow-stack compiler plugin.
I read the GC tutorial in the LLVM documentation, and the paper about
shadow-stacks. Im currently adding intrinsics to my generated llvm code,
and trying to write code to connected it to my (existing) garbage
collector library. Im not sure yet how everything fits together.