[LLVMdev] Marking *some* pointers for gc

David Chisnall David.Chisnall at cl.cam.ac.uk
Sun Jan 18 10:56:10 PST 2015


On 18 Jan 2015, at 18:40, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> 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.
> 
> 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?

The requirements ought to be captured by the nocapture attribute (though that still places some limitations on the GC - it isn't allowed to relocate an object while a pointer to it is passed to GC-oblivious code, which may not be an invariant that's easy to enforce in some designs).

I'm wary of an addrspaceany attribute though - we have different address spaces with different sizes and different register assignments for calling conventions, so this is a bit broad.  I'm not totally convinced by the use of address spaces to indicate GC vs non-GC pointers in this way, because we don't have a good way of describing interactions between address spaces in IR currently.  DataLayout can tell us the size and alignment for pointers to each AS, but can't currently tell us:

- Whether one address space is contained within another.

- Whether casts from one address space are lossy (if you do addrspacecast from n->m then back, are you guaranteed the same pointer?).

- Whether address space casts between a pair of address spaces are valid always, never, or sometimes.

Your addrspaceany is really a union of the two pointer types (which your high-level language's type system may or may not like), with the assumption that they have the same representation.

David





More information about the llvm-dev mailing list