[LLVMdev] llvm.gcroot suggestion

[Peter Housel]

On Wed, 2011-02-16 at 16:51 -0800, Talin wrote:
> 
> This approach offers a bunch of advantages that I can think of:
>       * LLVM knows much more about the liveness of values than the
>         frontend does, and could compute a much more optimal and
>         minimal stack map for each sync point. That is, two variables
>         whose lifetimes do not overlap can use the same stack location
>         for their roots to be stored in, and the stack maps generated
>         by the GCStrategy would reflect this.
>       * If at some future time LLVM supports register maps for garbage
>         collection, you would not have to update your frontend. Since
>         we're marking values, not stack slots, the frontend doesn't
>         have to care where the variable is stored, so all frontends
>         can take advantage of improvements in the representation of
>         stack maps.
>       * Writing frontends gets a lot easier, since the frontend is no
>         longer responsible for generating and initializing allocas for
>         every root. It also means a lot fewer opportunities for
>         generating incorrect code.
> What do you think?

I can't speak to the implementation, but as a potential user of this
facility I think this approach is definitely preferable to the current
one. The IR that the Open Dylan compiler is generating LLVM code from is
almost SSA already, and I don't want to allocate stack slots for
everything just for GC maps.

-Peter S. Housel-  housel at acm.org