similar to: [LLVMdev] getting closer!

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

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

Hi again Terence, On Apr 22, 2008, at 15:20, Terence Parr wrote: > Sorry for the long questions...gotta figure this out. Not a problem! > 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

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,

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

Howdy do LLVM folks! 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). Not sure this IR is correct but here is what I've been playing

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

On Apr 22, 2008, at 3:27 PM, Gordon Henriksen wrote: > If you'd like to propose clarified language once you've wrapped your > head around the framework, I'd be happy to incorporate it. Most > ideally, submit a patch against GarbageCollection.html in http://llvm.org/svn/llvm-project/llvm/trunk/docs/ > . Cool. Ok, I have already submitted some svn diffs to Chris to fix

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

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 Jul 26, 2008, at 10:32, Simon Ask Ulsnes wrote: > I forgot I still needed an answer to my original question. :-P > > So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and > llvm_gc_collect Yes. Your implementation of the llvm_gc_* functions should be compiled into a library and linked with your executable. > (llvm_cg_walk_gcroots is provided by the Collector

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

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

I just downloaded the source for release 2.2, and when I try to build 'make -C runtime' it fails with the following error: ---- [...] llvm[2]: Compiling semispace.c for Release build (bytecode) semispace.c:107: error: syntax error before 'ShadowStackEntry' semispace.c:107: warning: no semicolon at end of struct or union semispace.c:108: error: syntax error before '*'

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 Apr 22, 2008, at 5:43 PM, Gordon Henriksen wrote: > This is not possible for instructions (which must be in SSA form). You > can only use it for constants. > > http://llvm.org/docs/LangRef.html#constantexprs ah! ok, but really helpful for structs init. cool. >> I'm always using the pure text input headline generating everything >> from Java... > > Normally

Hi, I've been implementing a compiler that targets LLVM, and was looking into using the shadow-stack gc strategy. Currently, I build the runtime with clang (using -emit-llvm), and then link that with the LLVM bitcode output from my compiler using llvm-ld. This works fine without the gc strategy annotations and use of the llvm.gcroot intrinsic, but adding them causes some odd behavior: the

Forgot to CC the list. ----- Forwarded Message ---- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Trevor Elliott <trevor at galois.com> > Sent: Fri, January 14, 2011 7:33:15 PM > Subject: Re: [LLVMdev] LLVM GC > > Hi Trevor, > > Are you linking with LibStdC++ or LibC++? That is a requirement for running > code that has been compiled from C++

Hi Sam, I've not actually gotten to the linking process with my runtime, as I've compiled it with clang -emit-llvm -c, and then archived it with llvm-ar and llvm-ranlib. I'm also not producing a GC plugin, as I'm using the builtin "shadow-stack" strategy. My current build process looks like this: 1. build the compiler 2. build the runtime using clang -emit-llvm -c

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