llvm dev - Aug 2015 - RFC: alloca -- specify address space for allocation

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150826/2189a9ac/attachment.html>

> On Aug 26, 2015, at 8:24 PM, Matt Arsenault via llvm-dev <llvm-dev at
lists.llvm.org> 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
Just sent an email about this assumption in another thread ("Globals in
non-zero address spaces might be null” on llvm-commits):

"Isn’t something that should be target configurable? Any reason for not
having TTI with a default behavior which would be the current one, but that
targets could customize?"

But it also seems like we’re patching little hacks here and there to make the
address spaces usable, because they were not part of LLVM at the beginning and
we don’t have a real plan to make them first class (maybe it was considered and
the conclusion was that the effort wasn’t worth it?).

— 
Mehdi


> 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)
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=v-ruWq0KCv2O3thJZiK6naxuXK8mQHZUmGq5FBtAmZ4&m=hcouPrGSD1d8V3vg5Qr9CLgWQkGQ8kQPDsvXT48FGJU&s=k-ANzx_x7MeKLGQ1U-zGABf1JkLU5Ho_3-XQF-TUrbs&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150826/25c41b91/attachment.html>

> On Aug 26, 2015, at 8:24 PM, Matt Arsenault via llvm-dev <llvm-dev at
lists.llvm.org> 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)
+1

—Owen

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>

On 27 Aug 2015, at 07:40, Chandler Carruth via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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.
We have patches locally that allow you to specify the address space for allocas
in the DataLayout, because in one of our ABIs the stack moves to a non-zero
address space.  These would be relatively easy to extract, and if it’s an
approach that would be useful then I could probably post them for review this
week.

Having allocas in two address spaces seems plausible if they’re conceptually on
different stacks, but using them for GC’d allocations seems odd, as you’d need
to ensure that they were copied if live at the end of the stack frame,
effectively turning the model into a collection of garbage collected activation
records, rather than a stack.  For this use, I suspect that you’d need something
more like a gc-alloca instruction, which could be promoted to an SSA register if
its address isn’t taken, to a stack allocation if escape analysis can prove that
pointers to it don’t persist beyond the end of the function, or to a GC’d heap
allocation in other cases.

David