Displaying 20 results from an estimated 700 matches similar to: "[LLVMdev] Getting started with GC"
2004 Oct 27
0
[LLVMdev] Getting started with GC
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
2004 Oct 27
2
[LLVMdev] Getting started with GC
On Tue, Oct 26, 2004 at 11:17:00PM -0500, Chris Lattner wrote:
> On Tue, 26 Oct 2004, Tom Brown wrote:
> > $ llvm-as alloc_loop.ll
> > $ lli alloc_loop.bc
> > lli: Globals.cpp:81: llvm::GlobalVariable::GlobalVariable(const llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, const std::string&, llvm::Module*): Assertion `Initializer->getType() == Ty
2004 Oct 27
0
[LLVMdev] Getting started with GC
On Wed, 27 Oct 2004, Tom Brown wrote:
> On Tue, Oct 26, 2004 at 11:17:00PM -0500, Chris Lattner wrote:
> > On Tue, 26 Oct 2004, Tom Brown wrote:
> > > $ llvm-as alloc_loop.ll
> > > $ lli alloc_loop.bc
> > > lli: Globals.cpp:81: llvm::GlobalVariable::GlobalVariable(const llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, const std::string&,
2004 Aug 18
2
[LLVMdev] process_root.
Hi,
This is regarding the backend for garbage collection. My problem might be
related to some strange memory fault created by my frontend, but I'll try
here to get some feedback.
For some strange reason I get segmentation fault in process_pointer in
semispace.c (I've implemented a small collector, hopefully :). The fault
occurs when I do:
printf("process_root[0x%p] = 0x%p\n",
2004 Oct 28
2
[LLVMdev] Getting started with GC
We have a few questions about the current state of GC.
We decided to start (and finish?) our work by finishing SemiSpace.
process_pointer is meant to move objects from CurSpace to OtherSpace.
How can it find pointers to a moved object? How does it know the size
of each object? Assuming we are writing a GC that will only work from
llvm assembly our best option seems to be forcing the assembly code
2004 Aug 18
2
[LLVMdev] process_root.
On Wed, 18 Aug 2004, Reid Spencer wrote:
> On Wed, 2004-08-18 at 11:54, Tobias Nurmiranta wrote:
>
> Okay. I'm not an expert on GC but I'll take a look ...
Thanks :)
>
> > For some strange reason I get segmentation fault in process_pointer in
> > semispace.c (I've implemented a small collector, hopefully :). The fault
> > occurs when I do:
> >
>
2004 Aug 18
0
[LLVMdev] process_root.
On Wed, 2004-08-18 at 11:54, Tobias Nurmiranta wrote:
> Hi,
>
> This is regarding the backend for garbage collection. My problem might be
> related to some strange memory fault created by my frontend, but I'll try
> here to get some feedback.
Okay. I'm not an expert on GC but I'll take a look ...
> For some strange reason I get segmentation fault in process_pointer
2004 Oct 29
0
[LLVMdev] Getting started with GC
On Thu, 28 Oct 2004, Tom Brown wrote:
> We have a few questions about the current state of GC.
Ok. :)
> We decided to start (and finish?) our work by finishing SemiSpace.
Sounds good.
> process_pointer is meant to move objects from CurSpace to OtherSpace.
> How can it find pointers to a moved object?
This is entirely up to you, as you're basically implementing the semispace
2004 Aug 18
0
[LLVMdev] process_root.
Seems like Root in process_root sometimes is a null pointer. Wonder if it
is my fault? :) *debugging*
, Tobias
On Wed, 18 Aug 2004, Tobias Nurmiranta wrote:
>
> On Wed, 18 Aug 2004, Reid Spencer wrote:
> > On Wed, 2004-08-18 at 11:54, Tobias Nurmiranta wrote:
> >
> > Okay. I'm not an expert on GC but I'll take a look ...
>
> Thanks :)
>
> >
>
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:
>
> 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
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
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 Dec 12
1
[LLVMdev] Problem linking llvm_gc_collect
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
2008 Apr 22
3
[LLVMdev] getting closer!
Ok, I *might* be getting this from the assembly code. The assembly
code has:
L_llvm_gc_root_chain$non_lazy_ptr:
.indirect_symbol _llvm_gc_root_chain
.long 0
and I see it being used in the function preamble. Is that a ref to an
extern symbol or the def? I.e., is it referring to
StackEntry *llvm_gc_root_chain;
that I must have in my GC C code? (semispace.c has it)
SO!
2008 Apr 21
0
[LLVMdev] getting started with IR needing GC
Hi Terence,
On 2008-04-20, at 20:08, Terence Parr wrote:
> I've exhausted what I can do on my own to make a GC example bind
> (usual googling, reading, playing, looking at source). I can't find
> the shadow collector lib or perhaps the -l options needed to link my
> sample (not even to point where I'm figuring out GC actually as I
> can't link).
The shadow
2008 Apr 21
2
[LLVMdev] getting started with IR needing GC
On Apr 20, 2008, at 5:36 PM, Gordon Henriksen wrote:
> The shadow stack walker is in the runtime directory with the semispace
> heap example. The runtime directory is built to LLVM IR using llvm-
> gcc. So it's skipped unless you configure llvm with llvm-gcc support.
doh! That's how I missed the binary. thanks!
> Since the semispace heap doesn't actually work (it's
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