[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