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

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

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

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 code or so. > > > Ok, copying; can't find ShadowStackEntry though.

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!

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

On Apr 21, 2008, at 6:23 PM, Gordon Henriksen wrote: > On Apr 21, 2008, at 20:09, Terence Parr wrote: > >> Ok, I *might* be getting this from the assembly code. ... From >> that, it will push/pop in functions? If so, that's easy enough. :) > > Yup! Sounds like you've got it. Yup, what i was missing and what somebody should add to the doc is that

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 Sun, Apr 27, 2008 at 9:34 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > As for the compiler plugin interface, I suggest you ignore it > initially and use the provided shadow-stack option for the time being. > The shadow stack generates significantly suboptimal code, but will let > you avoid writing some platform-specific code. Instead, simply copy > the

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

On Apr 21, 2008, at 20:09, Terence Parr wrote: > Ok, I *might* be getting this from the assembly code. ... From > that, it will push/pop in functions? If so, that's easy enough. :) Yup! Sounds like you've got it. > What I was/am missing is the explicit link between types and > variables in a GC.c file and the generated machine code. If I can > get that last

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)

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

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

2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > I'm not sure the purpose of doing so—llvm::Collector (poorly named; > I'm open to suggestions) exists only in the compiler, not at runtime > in the compiled program. You should need access to it at runtime no > more than you might need access to an instance of llvm::TargetMachine. Maybe I don't understand the

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