[LLVMdev] Improving Garbage Collection

[Cameron Zwarich]

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 responsibility for copying stack roots to memory, from the frontend to the LLVM code generators.
> Let me take the last point first.
> 
> Proposal Pt 3: Copying Stack Roots to Memory
> 
> 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. So the LLVM libraries should take over the job of creating local allocas for holding SSA values during a safe point, as well as the job of copying those SSA values to those allocas.
> 
> Of course, generating "optimal" code (as outlined in the previous section) would require a lot of work to the backends. But we don't need to do that right away. The first goal should be a "conservative, pessimistic" implementation that's no better or worse than what we have today (other than being far easier to use.) It might be possible to do this as some sort of stand-alone transformation/lowering pass.
> 
> This is what I mean by an evolutionary approach - come up with the right interface between the frontends and LLVM that enables us to gradually move towards that eventual goal.

The initial step of your evolutionary approach sounds basically equivalent to what is possible today. When you try to go beyond that you will run into a lot of issues, since the backend is untyped and doesn't even distinguish between pointers and integers. The closest thing we have to tracking liveness of SSA values throughout the backend is debug info, which is frequently incorrect (although usually not due to the code generator itself).

Who is going to implement support for all of this in the code generator passes and maintain it? Will GC compatibility be a requirement for any further improvements in code generation?

Cameron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110707/c201fb52/attachment.html>