[llvm-dev] RFC: alloca -- specify address space for allocation

[Chandler Carruth via llvm-dev]

On Wed, Aug 26, 2015 at 8:25 PM Matt Arsenault <Matthew.Arsenault at amd.com>
wrote:

> On 08/26/2015 07:02 PM, Chandler Carruth via llvm-dev wrote:
>
>
> Without a better understanding of both the motivation and the resulting
> consequences such as what I've outlined in my questions above, it is very
> hard for me to feel comfortable with this kind of change.
>
> For my use case, some of the assumptions about addrspace(0) don't make any
> sense, so having the option of not using it for stack allocations would
> avoid some special case problems. For example, it's assumed that 0 is the
> address space of code, and stack, but for us these are unrelated concepts
> and have different pointer sizes. The assumption that 0 is not a valid
> pointer value is also incorrect, since we want stack pointers to be a
> 32-bit offset and 0 is valid. For this use case, all allocas should be
> created with the same address space, so it could be part of the datalayout.
> In the backend, we have 3 different memory types we would like to place
> stack objects, so being able to mark these with different address space IDs
> would also be helpful (although we wouldn't care about the middle end
> deciding that some allocas should be in a different address space from a
> single one specified by the data layout)
>

FWIW, these use cases seem really straight forward for address spaces. For
example, I don't think any of my questions about the semantics apply. It
seems straight forward to define a set of allowed address spaces for
allocas in the data layout, and a default address space[1] for them that
the optimizer could use if it creates or fuses allocas in ways that leave
some ambiguity.

But this is very different from the idea of using an alloca with an address
spaces for GC pointers to stack objects...

Anyways, if this kind of support of specific address space stack
allocations to better utilize a diverse memory hierarchy is of interest,
pursuing that makes a lot of sense to me provided we specify a good
semantic model for the optimizer to follow when interacting with them...

-Chandler

[1]: I actually also really agree with Mehdi here that things like a
"default" address space (and the fact that for your target "0" isn't really
a great default today) are maybe more of an issue with LLVM having
unfortunate legacy. I'm inclined to think we should fix LLVM to let "0" be
a reasonable default for allocas to simplify the work needed in the
optimizer. But i've not spent a ton of time thinking through this set of
issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/bdb8cbd3/attachment.html>