[PATCH] D31042: Allow DataLayout to specify addrspace for allocas.

John McCall via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 28 15:54:22 PDT 2017


rjmccall added a comment.

In https://reviews.llvm.org/D31042#712613, @arsenm wrote:

> In https://reviews.llvm.org/D31042#712484, @rjmccall wrote:
>
> > >> Because LLVM currently makes some unfortunate assumptions about address space 0, this stack address space cannot be address space 0.  These assumptions include:
> > >>  (1) As far as debug info is concerned, the size of a pointer is the size of a pointer in address space 0.  (Is this assumption why sizeof(void __private *) == 8 despite __private being clearly intended in the OpenCL spec to be the address space of stack pointers?)
> > > 
> > > This is a point that the spec is vague on. While the spec explicitly allows different size pointers for different address spaces, there isn't really any detailed description of what this entails.
> >
> > I don't see what the problem is.  The spec doesn't allow pointers to be converted between address spaces at all (except for the promotion into the generic address space in OpenCL 2.0).  Pointers into different address spaces are just completely different types.
>
>
> The problem is mostly what happens if the host and device pointer size don't match? Struct layouts etc. still need to be compatible for whatever memory buffer was passed into the kernel. There isn't much practical reason to do it, but you could have a struct with private pointer members in it changing the offsets of the other items, not that you could do anything valid with the contents.


The easy lowering would be to leave a 64-bit __private address space around but consider it "illegal".  Address space conversions between it and the 32-bit __private address space would simply be zexts and truncs.  But your 8-byte-aligned pointer idea works, too, assuming it doesn't give LLVM too many fits to have an over-aligned primitive type.

The more complex lowering would be to rewrite all the struct types to replace T addrspace(__private64)* with { T addrspace(__private32)*, i32 }.  There's actually relatively few IR constructs that work with struct types — GEP, insertvalue/extractvalue, constant aggregates, I think that's it.  The IR type would change alignment, but only by getting weaker, and memory accesses should all have explicit alignments anyway.

Anyway, I guess we're getting a bit afield.

John.


https://reviews.llvm.org/D31042





More information about the llvm-commits mailing list