[LLVMdev] GC questions.

[Chris Lattner]

On Thu, 22 Jul 2004, Tobias Nurmiranta wrote:
> > Unfortunately this won't really work.  It might be reasonable to include
> > something like this in the front-end that you're working on, but including
> > this at the LLVM level is a bad idea.  The basic idea of the alloca model
> > is that it directly exposes to the optimizer the fact that GC pointers may
> > change at unpredictable times, which is something that memory can do, but
> > SSA registers do not do.
>
> Ok. But if the gcroot_value transformation in done before any
> optimizations, I get the same result as if I had used gcroot and alloca.
> So maybe I can move it to a independent pass which I then use with my
> frontend.

Keeping it as part of your front-end is fine, but including it with the
LLVM distro is not.  The problem is that the pass subtly changes the
semantics of the LLVM instruction, which is a bad thing for many reasons.
What the pass really does is create a dialect of LLVM, one which is easier
for you to produce in your front-end, and that is easily translatable to
standard LLVM form.

> Hmm, it felt nicer to mark raw LLVM pointers as roots and then transform
> them, since I then didn't have to see the overhead in my frontend :).

I'm not sure what overhead you mean.  I understand that you basically have
a single-assignment source language, so you don't need to deal with
alloca's in the usual case, but every other front-end we have produces
alloca instructions for EVERY user defined variable, regardless of whether
it's a GC root.  Obviously most of these get optimized away :)

> Btw, how hard would it be to implement the system described in this
> paper[1], support for collection at every instruction? You would need to
> get the gc root information with you all the way down to machine code and
> register allocation. Just curious :).
> [1] http://portal.acm.org/citation.cfm?id=301652&dl=ACM&coll=portal

I don't understand what the benefit of this would be.  The problem is that
once dynamically assigned, an SSA value cannot change its contents until
it is redefined by the same definition.  Tracking GC information at every
instruction would not be able to address this fundamental problem.

LLVM *does* have a way to represent something that can change like we
want... I'm not sure why you're so afraid of it!  :) :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/