similar to: [LLVMdev] GC infrastructure checked in

On Monday 07 January 2008 02:32:47 Gordon Henriksen wrote: > Everything described in GarbageCollection.html should now be live. Phew! > > The collectors could use a review, but they compile, have no impact > unless used, and tests would otherwise have had to be XFAILed waiting > on them. > > The ShadowStackCollector has one issue that may be of interest in that > it adds

On 2008-01-07, at 05:29, Jon Harrop wrote: > On Monday 07 January 2008 02:32:47 Gordon Henriksen wrote: > >> Everything described in GarbageCollection.html should now be live. >> Phew! >> > > This is wonderful news! Are there any example programs using these > GCs? The division of labor is such that the user program must provide the stack walker (in

Gordon Henriksen wrote: > On 2008-01-07, at 05:29, Jon Harrop wrote: > >> On Monday 07 January 2008 02:32:47 Gordon Henriksen wrote: >> >>> Everything described in GarbageCollection.html should now be live. >>> Phew! >>> >> This is wonderful news! Are there any example programs using these >> GCs? > > The division of labor is

On Jan 7, 2008, at 10:54, Carl Friedrich Bolz wrote: > Gordon Henriksen wrote: > >> That said, the PyPy group has llvmgcroot support on a branch; you >> could ask Armin Rigo <arigo at tunes dot org> for details about >> accessing it. >> >> On his benchmarks, Armin saw an 8% speedup vs. a shadow stack. >> Their gcc backend still outperforms

Hello, Everyone > That said, the PyPy group has llvmgcroot support on a branch; you > could ask Armin Rigo <arigo at tunes dot org> for details about > accessing it. FYI: some status report can be seen here: http://codespeak.net/pipermail/pypy-dev/2008q1/004441.html -- WBR, Anton Korobeynikov

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

I'm trying to add gcoot functionality to my code and I'm confused by why gcroot is assuming to be an i8** I'm using i32 as object and array pointers and if I make them i8 things seem to work. I'm generating IR much like http://llvm.org/docs/GarbageCollection.html#llvm-ir-features void @llvm.gcroot(i8** %ptrloc, i8* %metadata) -------------- next part -------------- An HTML

Hi all, I would like to implement GC for a language supporting multiple threads. There will be no shared state between threads as communication will be based on message passing. I do not care much about performance. The priority for me is to get things working. I have read LLVM guide on writing GC: http://llvm.org/docs/GarbageCollection.html. Shadow stack approach looks very promising. The

On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > > If so, then a Collector plugin would need to have info about every > > supported backend lays out the runtime stack? > > Yes. This information is actually available in a target-independent > fashion with LLVM, so the Collector interface is target-independent. A > backend

Hi Dominic, +//===-- llvm/Support/IRBuilder.h - Builder for LLVM Instrs -----*- C++ -*-===// is this line the right length? It seems shorter than the similar lines below like this one: +//===----------------------------------------------------------------------===// + GetElementPtrInst *CreateStructGEP(Value *Ptr, unsigned Idx, + const char *Name =

On 2008-04-28, at 21:19, Lane Schwartz wrote: > On Mon, Apr 28, 2008 at 2:13 PM, Gordon Henriksen <gordonhenriksen at mac.com > > wrote: > >>> If so, then a Collector plugin would need to have info about every >>> supported backend lays out the runtime stack? >> >> Yes. This information is actually available in a target-independent >>

Gordon Henriksen wrote: >> Hm, summary: >> >> pypy-llvm-backend with llvm's codegen >> < pypy-c-backend with GCC >> < pypy-llvm-backend using llvm's C backend and then GCC > > I wonder what the impact of using llvm-gcc instead of GCC is in this > final pipeline. If that actually works, you could indeed eliminate the > shadow stack

Duncan Sands wrote: > + GetElementPtrInst *CreateStructGEP(Value *Ptr, unsigned Idx, > + const char *Name = "") { > + llvm::Value *Idxs[] = { > + ConstantInt::get(llvm::Type::Int32Ty, 0), > + ConstantInt::get(llvm::Type::Int32Ty, Idx) > + }; > + return Insert(GetElementPtrInst::Create(Ptr, Idxs, Idxs+2, Name));

Hello! I'm looking at "Overview of available features" here: http://llvm.org/docs/GarbageCollection.html#collector-algos and can't understand something. First, does table header mean that there are already some GC's implemented besides "shadow stack"? E.g. can I just use them? Second, does row "JIT", "NO" mean that GC is not compatible with

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

Thank you so much for your help! I now have a much clearer idea of how to proceed. :-) This just keeps getting more interesting. - Simon 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > On Jul 26, 2008, at 12:14, Simon Ask Ulsnes wrote: > > 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > > I'm not sure the purpose of doing so—llvm::Collector

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

2008/7/24 Gordon Henriksen <gordonhenriksen at me.com>: >> OK, so for instance if I wanted to be able to use the GC from a C >> frontend (presumably by using llvm_gc_allocate?), do the C functions >> need this attribute as well? > > Yes. I forgot I still needed an answer to my original question. :-P So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and