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

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added a comment.

In https://reviews.llvm.org/D31042#711596, @rjmccall wrote:

> What else in LLVM actually hard-codes 0 as the assumed address space?  Intrinsic function declarations?  Optimizations that create new globals (if there are any?)  Wouldn't it be much less invasive to change those and leave the assumption that the stack is in addrspace 0?


I'm not sure what you are suggesting. The concept of assumed address space doesn't make any sense on AMDGPU. Everything has an address space. This isn't changing how address space 0 is treated, and is specifically avoiding doing so. AMDGPU does want the assumed address space 0 properties, just for some of the other address spaces that are not the stack address space, which is one of the advantages of making this change. The problem isn't really places hard coding 0 as the address space, it's the properties of the stack address space do not behave like LLVM's notion of the generic address space as I mentioned in the RFC.

As far as 0 being a valid stack pointer, we currently have a workaround of not allocating user objects there. The bigger issues in my mind is that the pointer size for the stack does not match the code pointer size, which is a problematic area which keeps popping up. Another is it is not valid to addrspacecast any other address space to the stack address space. One partial alternative would be to introduce a code pointer size to the datalayout or code address space or something along those lines. I think that would still leave a conceptual gap between AMDGPU's stack and alloca, and be more of a hassle. (For example you still cannot addrspacecast any pointer to the address space of the stack).

There are some intrinsics which hard code 0, some of which need to be fixed (such as lifetime intrinsics which https://reviews.llvm.org/D31041 and https://reviews.llvm.org/D31043 take care of) but other than that one that's mostly a different question. There is a jump table optimization which creates new globals (which is disabled if BR_JT is illegal). Moving AMDGPU's flat address space to match LLVM's generic address space would also have the advantage of allowing legal addrspacecasts to address space 0 for some of these intrinsics.


https://reviews.llvm.org/D31042