similar to: [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

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: > > >

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 :) > > > >

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 checked out from cvs a few days ago, similar output with release 1.3) $

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

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

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&,

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, 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: > > 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

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

Hi, Regarding llvm.gcroot, do I have to allocate stack-space for all pointers in a function? Right now I mostly use SSA-variables, and let llvm's register allocation allocate stack-space when needed. Also, what happens when I run the mem2reg pass, does it handle llvm.gcroot's that are moved from stack to registers? I'm thinking along the lines, that should one not use llvm.gcroot on

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

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

On Sat, 17 Jul 2004, Chris Lattner wrote: > > http://www.ida.liu.se/~tobnu/scheme2llvm/ > > Looks great! > > > (what's a blurb? :) > > Just a summary, so that I can add an entry to this page: > http://llvm.cs.uiuc.edu/ProjectsWithLLVM/ Maybe this for now: "This is a small self applicable scheme compiler for LLVM. The code is quite similar to the code in

Hello Lang, thanks for the suggestion :) it's very interesting. I'll take a read to the email you've pointed out there to understand how it works. Btw, does this mean that only your allocator is able to handle or support this type of constraint? As a follow up to my previous email, the following code is a real example of what i was explaining, Lang this example is exactly why i need

Dear R helpers,   I have following input files. (Actually they are more than 10 rates but here i am considering only 2 rates to write my problem)   rate1.csv min1        max1            min2          max2          min3           max3 1.05        1.30               1.30          1.65             1.65          1.99   rate2.csv min1        max1            min2          max2          min3          

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

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

On Mon, 19 Jul 2004, Tobias Nurmiranta wrote: > Regarding llvm.gcroot, do I have to allocate stack-space for all > pointers in a function? Right now I mostly use SSA-variables, and let > llvm's register allocation allocate stack-space when needed. Yes. This reflects the fact that the GC can move objects (to compact the heap) at unpredictable times. > Also, what happens when I