[LLVMdev] GC questions.

[Chris Lattner]

On Thu, 22 Jul 2004, Tobias Nurmiranta wrote:

> Ok, here's the new patch.

Looks great, thanks!  I've applied the patches here:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040719/016339.html
through here:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040719/016344.html


> (Please tell me if I shouldn't mail patches directly on the mailing
> list.)

In general patches should be sent to the llvmbugs list, but this subject
has some design discussion, so it's ok for it to be on llvmdev :)

> While I was editing LowerGC.cpp I made a little test (not part of this
> patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new
> intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer
> directly instead and transforms it into an alloca. The idea is the
...
> In this way, the frontends don't have to explictly alloca the gcroots,
> but instead just use the intrinsic, which hides how the gcroots are
> implemented.

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.

In particular, if the pointers are exposed as raw LLVM pointers, the
optimizer might start doing transformations to the pointers that break the
program.  The reason for the current design is that it is guaranteed to
disable any optimizations that might break the program, while it allows
gc-aware optimizations to notice the GC roots and do something trickier on
a case by case basis.  The important thing is that we default to being
safe, while allowing snazzy smart optimizations at the same time.

Currently the code generators don't do anything particularly smart with
the GC pointers, so they end up living in actual memory.  As the code
generators mature, however, I expect this to change.  :)

I hope this makes sense.  If not, please feel free to ask for
clarification.  Thanks for the patches!!

-Chris

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