[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#711771, @rjmccall wrote:

> In https://reviews.llvm.org/D31042#711662, @arsenm wrote:
>
> > In https://reviews.llvm.org/D31042#711661, @rjmccall wrote:
> >
> > > In https://reviews.llvm.org/D31042#711648, @arsenm wrote:
> > >
> > > > LLVM treats 0 as the "generic" address space. This is how the LangRef refers to it.
> > >
> > >
> > > You're revising LangRef here one way or the other.  I'm suggesting that a better revision would be to stop saying that address space 0 is the "generic" address space (because there is no such thing), and instead say that it is the address space of the stack.  Is there anything actually preventing you from doing that?
> >
> >
> > Yes. The pointer size of the stack smaller than the pointer size for code or most other memory. 0 is a valid, dereferencable pointer for the stack address space
>
>
> I don't see why the pointer size has anything to do with it.  In the absence of target-specific information, LLVM is not allowed to assume that one address space is subsumed by another address space at all.  It doesn't matter if one of them is address space 0.
>
> The special treatment of zero pointers is an interesting point, but again, I feel like that transformation could be made target-dependent *much* more easily than this.  This is an incredibly invasive change.


I think being able to opt out of any assumptions is CHERI's use case for this patch, but I don't work on that so I'm not sure.

The relationships between different address spaces is only indirectly related to adding an address space to alloca, and is more a useful side effect. I think LLVM's assumptions about pointers and address space 0 (and worse so, clang) are more widespread than you think. There is no concept of a code pointer size. This is one area where address space 0 is treated as a lack of an address space. The code size and stack pointer do not have the same size for AMDGPU, and it is important to be able to distinguish these. There is a lot of code that assumes the default address space size is "the one true pointer size". You can't pass around a 64-bit function pointer properly if it's required to have the same properties as a 32-bit stack pointer. It isn't really OK to start treating function pointer types differently than other types. Fixing that is an uphill battle in the frontend and backend. It is less work to align the AMDGPU generic address space notion with LLVM's "default" address space and the assumptions made about it than to fix everything else. Adding address spaces to functions would be a much more invasive change. I don't think adding this DataLayout argument is very invasive, and was less work than I anticipated (The IRBuilder changes could also be avoided by getting the DataLayout from the insertion block's parent module). There is no big semantic change, just simple bookkeeping updates.

The pressing reason for this is C++ GPU support. Clang's handling of address spaces is more problematic. The assumptions about address space 0 are more widespread and tied to LLVM's address space 0. The work to start annotating every pointer there as required would be a much more invasive change.


https://reviews.llvm.org/D31042