[LLVMdev] Marking *some* pointers for gc

[Philip Reames]

On 01/18/2015 10:40 AM, Ramkumar Ramachandra wrote:
> Sanjoy Das wrote:
>> In your
>> example, foo will have to treat its argument differently depending on
>> whether it is a GC pointer or not.
> In practice, this is not true of many functions that don't call other
> functions. Take the example of a simple "print" function that takes a
> void * to cast and print, type_int to determine what to cast to: why
> should it care about whether the pointer is GC'able or not? In the
> callsite, I have this information, and I accordingly emit
> statepoint/relocate information. But "print" doesn't call other
> functions, and doesn't need to emit statepoint/relocate.
You are right that there are some functions which can not trigger 
garbage collection and thus are not sensitive to the 'type' of the 
pointer they've been given.  I've been calling such functions "gc leaf 
functions" for lack of a better name.  However, there's a good chance 
that your "simple print function" is not, in fact, such a function.  If 
your print routine contains any non gc-leaf call, or a loop whose bounds 
are not known at compile time, it may in fact need to do relocation.  
Depending on your collector, the routine may also need a load or store 
barrier for one or the other uses.  It's highly unlikely that the code 
between the GC address space and the non-GC address space is actually 
the same.

There's lots of room to experiment with a gc-leaf function attribute, 
and - in particular - the inference of such.

Having said all that, I'm really curious why this matters to you. In 
practice, we haven't found there to be many functions at all which are 
needed on both gc and non-gc pointers (where the function is *also* a 
gc-leaf.)  Unless you're seeing a bunch of cases like this, I'd just 
duplicate the shared routines.
>
> Let's say I made the void * argument addrspace(0). Then, in callsites
> where I have an addrspace(1) to pass, I have to emit:
>
>    addrspacecast 1 -> 0
>    call print
>    addrspacecast 0 -> 1
>
> Is the ideal workflow, or should we have some sort of addrspaceany?
I strongly advise against introducing such casts.  Doing so makes it 
much harder to reason about correctness.  I would be open to a proposal 
of an "generic address space" mechanism, but that's a large project.  I 
don't really see the motivation for it currently.  You'd need to send a 
proposal to llvmdev and get feedback on the idea.

Philip