similar to: [LLVMdev] Improving Garbage Collection

On Fri, Feb 18, 2011 at 1:05 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: >> >> Thinking about it even more, here's a short summary of what I would >> propose: >> >> - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage

Hi Talin, On Fri, Feb 18, 2011 at 5:50 PM, Talin <viridia at gmail.com> wrote: > > > In the current scheme, the way you tell LLVM that a root is no longer > needed is by assigning NULL to it. However, that assumes that all roots are > pointers, which is not true in my world - a root can be a struct containing > pointers inside of it. (In my current frontend, a non-pointer

On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > I think I'm one of the few people actually using LLVM's support for garbage > collection, and so far I've found it very difficult to generate code that > uses llvm.gcroot() correctly. > > In the current scheme, it is the frontend's responsibility to insure that > any intermediate SSA

On Thu, Feb 17, 2011 at 1:07 PM, Talin <viridia at gmail.com> wrote: > On Wed, Feb 16, 2011 at 4:51 PM, Talin <viridia at gmail.com> wrote: > >> I think I'm one of the few people actually using LLVM's support for >> garbage collection, and so far I've found it very difficult to generate code >> that uses llvm.gcroot() correctly. >> >> In

I think I'm one of the few people actually using LLVM's support for garbage collection, and so far I've found it very difficult to generate code that uses llvm.gcroot() correctly. In the current scheme, it is the frontend's responsibility to insure that any intermediate SSA values containing references to garbage collectible objects are copied to stack variables so that the GC

On Mon, Feb 21, 2011 at 1:50 AM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > On Fri, Feb 18, 2011 at 5:50 PM, Talin <viridia at gmail.com> wrote: >> >> >> In the current scheme, the way you tell LLVM that a root is no longer >> needed is by assigning NULL to it. However, that assumes that all roots are >> pointers,

So - here's a really modest proposal: Based on Renato's suggestion, there is a way to associate arbitrary annotation data with any LLVM type. So what I would propose as a first step is to simply replace (or perhaps supplement) the current llvm.gcroot() feature with a type annotation. That is, LLVM would only support roots that are allocas, just it does today. The backend code would not

On Jul 6, 2011, at 3:24 PM, Talin wrote: > Overall Proposal: Support marking SSA values as roots (an evolutionary approach) > > My proposal consists of three rather significant changes to LLVM: > Allow frontends to mark SSA values - or even portions of SSA values - as stack roots. > For alloca roots, add a way to communicate to LLVM when a root goes out of scope. > Transfer the

Sorting through all of the discussions would be difficult, as the ideas have morphed over the years. Also, some of the discussion took place offline at various LLVM dev conferences. I can summarize the main points here: The biggest improvement in GC would be to allow SSA values to be declared as GC roots - currently only alloca values, that is, values in memory, can be GC roots. This means that

Actually, I'm pretty happy with the way that LLVM handles this aspect of garbage collection now. LLVM does not itself generate any data related to garbage collection - all it does is supply a plugin interface that lets your code know where on the stack the roots are. Your code is responsible for generating any static data structures that would be read by your garbage collector. So if you

Just a thought, but it would it make sense for garbage collection to be some sort of minimal debug information for potentially optimized code. Store just enough debug information to reconstruct call stacks and know where gc-roots are. Perhaps an approach like this could minimize the work required as it is shared between gc-support and debug information support. >From what I understand, DWARF

I realize that this was written in a hurry, and may not have been entirely clear. If there are any questions, critiques, etc., I'd be happy to respond to them. I'd really like it if LLVM's garbage collection support didn't continue to languish... On Fri, Apr 6, 2012 at 12:43 PM, Talin <viridia at gmail.com> wrote: > Sorting through all of the discussions would be

On 07.07.2011 08:31, Nate Fries wrote: > On 7/6/2011 6:24 PM, Talin wrote: >> The LLVM code generators and analysis passes have a much more >> thorough knowledge of SSA value lifetimes than frontends do, and >> therefore could avoid spilling and reloading of values when it wasn't >> needed. > Although this would indeed be nice, it is not done by similar >

On 7/6/2011 6:24 PM, Talin wrote: > The LLVM code generators and analysis passes have a much more thorough > knowledge of SSA value lifetimes than frontends do, and therefore > could avoid spilling and reloading of values when it wasn't needed. Although this would indeed be nice, it is not done by similar platforms in practice. I have investigated [very] briefly into whether the

Hi Talin, On Fri, Feb 18, 2011 at 1:36 AM, Talin <viridia at gmail.com> wrote: > > Thinking about it even more, here's a short summary of what I would > propose: > > - *llvm.gc.value*(value, metadata) - marks an SSA value as a garbage > collection root. This remains in effect for the lifetime of the SSA value. > - *llvm.gc.declare*(alloca, metadata) - marks

Hi Talin, Let me ask a question before we go too much further. Currently the argument > to llvm.gcroot must be an alloca instruction. You cannot GEP an internal > field within the alloca and pass it to the gcroot intrinsic. So the entire > alloca is considered a root, even if it has non-pointer fields. My question > is, in this new address-space proposal, are we talking about changing

(This is a summary of the big long thread on llvm.gcroot, for those who didn't have time to read it.) I'm proposing the replacement of llvm.gcroot() with three new intrinsics: - *llvm.gc.declare*(alloca, meta). This intrinsic marks an alloca as a garbage collection root. It can occur anywhere within a function, and lasts either until the end of the function, or a until matching

Now that the statepoint changes have landed, I wanted to start a discussion about what's next for GC support in LLVM. I'm going to sketch out a strawman proposal, but I'm not set on any of this. I mostly just want to draw interested parties out of the woodwork. :) Overall Direction: In the short term, my intent is to preserve the functionality of the existing code, but migrate

Hi Talin, On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: > > > So I've been thinking about your proposal, that of using a special address > space to indicate garbage collection roots instead of intrinsics. Great! > > To address this, we need a better way of telling LLVM that a given variable > is no longer a root. > Live variable

On Mon, Mar 7, 2011 at 4:08 AM, nicolas geoffray <nicolas.geoffray at gmail.com > wrote: > Hi Talin, > > On Sat, Mar 5, 2011 at 6:42 PM, Talin <viridia at gmail.com> wrote: >> >> >> So I've been thinking about your proposal, that of using a special address >> space to indicate garbage collection roots instead of intrinsics. > > > Great!