[LLVMdev] llvm.gcroot suggestion

[Kenneth Oksanen]

On Wed, 2011-02-16 at 16:51 -0800, Talin wrote:
> [..] the frontend is forced to generate very inefficient IR, with
> dozens of alloca slots at the beginning of the function, each marked
> as a root. It also has to initialize each of these roots to a known
> value, even if the root is only "live" for a very small part of the
> CFG. This is because currently there's no way for the frontend to tell
> LLVM that a given root has a limited lifespan (since calls to
> llvm.gcroot also have to be in the first block), and so you have to
> take a conservative approach and treat every root as if it were live
> for the entire function. [..]

I can confirm this observation.  The generated code is clearly
suboptimal, and it gets even worse if one tries to do live-precise
garbage collection where the gcroot'ed alloca-slot no longer used must
be explicitly assigned a null value.  On my list processing
micro-benchmarks these effects incur a performance hit of approximately
20%-30% compared to a manually crafted asm code, and that is including
the overhead of the garbage collector.

> It seems to me that "gc-rootness" should not be an aspect of an
> alloca, as it currently is now, but rather an aspect of a Value [..]

I'ld second that.

-- 
; mailto:cessu at iki.fi  http://www.iki.fi/~cessu  http://cessu.blogspot.com
((lambda(a) (a a((lambda(a)(lambda()(set! a(+ a 1))a))1)))(lambda(a c)
((lambda(b) (newline)(write b)(a a((lambda(c)(lambda()(c c)))(lambda(a)
((lambda(c) (if(=(modulo c b)0)(a a)c))(c))))))(c)))) ; Scheme me!