First of all, thanks for looking into this! As you've no doubt discovered, I'm one of the people who has talked a lot about this issue in the past, and have been frustrated with the lack of progress in this area.<div>
<br></div><div>I completely agree with your point about wanting to be able to attach GC metadata to a type (rather than attaching it to a value, as is done now). In the past, there have been two objections to this approach: first, the overhead that would be added to the Pointer type - the vast majority of LLVM users don't want to have to pay an extra 4-8 bytes per Pointer type. And second, that all of the optimization passes would have to be updated so as to not do illegal transformations on a GC type.</div>
<div><br></div><div>A different approach would be to create a new kind of derived type that associates metadata with an existing type. This "AnnotatedType" would be essentially a tuple (type, metadata), and would be constant-folded just like other types are. Just like the existing GC intrinsics today, there would be some way for a post-optimization pass to get access to all of the stack variables an examine the annotations on each to determine how to construct the appropriate static data structures.</div>
<div><br></div><div>This approach has both a number of advantages and a number of challenges. The first advantage is that it means that LLVM users who aren't interested in GC would pay nothing. A second advantage is that this could also be used to wrap types that are not pointers. One use case I have is being able to handle a discriminated union type which sometimes holds a pointer and sometimes doesn't. The existing intrinsics allow this use case (within the limitations that you point out) - the way it works is that the entire struct is considered a "root" and is passed through to the GC plugin, which generates code to look at the discriminator field and decide whether to trace it or not. However, I'm also aware of the fact that I seem to be the only one who is interested in this particular case, so I won't strongly object if your solution doesn't handle it, as long as the existing intrinsics continue to work.</div>
<div><br></div><div>The challenge of this approach is that a lot of backend code will need to unwrap the annotated type in order to operate upon it, and it would be all too easy to discard the associated metadata as part of this process.</div>
<div><br></div><div><div><div><div class="gmail_quote">On Fri, Dec 28, 2012 at 1:09 PM, Benjamin Saunders <span dir="ltr"><<a href="mailto:ralith@gmail.com" target="_blank">ralith@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm working on an LLVM backend for Idris, a garbage-collected pure<br>
functional programming language, and have experienced some frustration<br>
that LLVM's GC support, specifically with regard to mapping roots,<br>
operates only on allocas. This entails a lot of otherwise unnecessary<br>
stack allocation (especially in a pure language, where in-place<br>
mutation is rare) and imposes limitations on what optimizations can be<br>
applied. Other LLVM users have used elaborate workarounds to this,<br>
such as Rust's use of address spaces and, I believe, GHC's specialized<br>
calling convention. I'm interested in extending LLVM to support GC<br>
roots in regular SSA values, but, that being a significant change,<br>
it's clear that some discussion is in order before diving in if I want<br>
to get such a patch merged.<br>
This topic has been discussed on multiple previous occasions, and in<br>
each case nothing seems to have come of it, though interest appears to<br>
be significant. In particular, concerns with how such infrastructure<br>
could be made to abide by the invariants of arbitrary GC algorithms<br>
seem to have stayed hands. It's not clear to me why that poses a<br>
problem--if the property of being a GC root is correctly propagated<br>
through all manipulations of a pointer, and that information tracked<br>
through register allocation and made available to the GC metadata<br>
printer, won't the the resulting system have no more limitations or<br>
constraints than the current one? A copying collector would, having a<br>
complete list of root locations, still be able to rewrite them; a<br>
mark-and-sweep collector would still be able to find everything in<br>
need of marking; and so on.<br>
If my understanding above is correct, then perhaps the challenge lies<br>
in correctly propagating the marking of a pointer in an SSA value as a<br>
root through transforms. The pattern of propagation desired seems<br>
identical to that of type information, so perhaps it would be best to<br>
make the marking of a pointer as a GC root an attribute of its type,<br>
much the way address spaces already work? Recall again Rust's approach<br>
here, where the behavior of address space information through<br>
transforms is exactly what is relied upon.<br>
It's easy to imagine a GC root flag on pointer types, but one still<br>
needs to attach metadata to enable tagless GC as supported by the<br>
existing infrastructure. Rust simply encodes this information into the<br>
address space number; a similar approach could be envisioned with a<br>
'GC type ID' number that could be used by the GC metadata printer to<br>
look up detailed information in e.g. module-level metadata, but this<br>
is a bit awkward; it would be nice to have an interface at least as<br>
convenient as the current intrinsic is. If the metadata is uniqued so<br>
as not to break type equality and uniquing, would it be viable to have<br>
the GCd pointer type itself refer to a metadata node?<br>
Finally, is there anything else that needs consideration before attempting this?<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>-- Talin
</div></div></div><div><br></div>