[llvm-dev] RFC: alloca -- specify address space for allocation
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 26 20:34:27 PDT 2015
> 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?).
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev