[LLVMdev] Improving Garbage Collection

[Andrew Trick]

On Jul 11, 2011, at 2:28 PM, Talin wrote:

> 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 change at all, except that in addition to detecting the presence of the llvm.gcroot marker, it would also detect the presence of a type annotation. That means that *every* alloca of a given type would be considered a root - there would be no need to insert the llvm.gcroot intrinsic into each function.
> 
> Later we could think about supporting SSA local variables, parameters, and register maps. But this first step is a prerequisite for all of those other things, and I'm thinking that it's a relatively easy step compared to the others.
> 
> -- Talin

I may have some fundamental misconceptions of how gcroot works for you today. If you can clarify it for me, then I can better understand your proposal. I always assumed that an essential side effect of the gcroot() intrinsic was to take the address of a local variable, implicitly preventing optimization. But your recent comments indicate that gcroot does nothing beyond annotating a value. Without gcroot, what prevents mem2reg from promoting the alloca? Furthermore, what prevents optimizations such as GVN from optimizing access to the local variable across call sites? I assume stack variables that don't "escape" are fair game for all the usual scalar optimizations--but I could be wrong.

-Andy