[cfe-dev] default address space of pointers is generic in CL2.0 mode

[David Chisnall]

On 6 Aug 2015, at 18:14, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:
> 
> On 08/06/2015 06:40 AM, David Chisnall wrote:
>> I’m not sure exactly what this entails for OpenCL, but I have patches that allow the default AS in clang to be non-zero (and to LLVM to support a stack in a non-0 AS) that I could probably disentangle in about two weeks (or could point someone else at if they wanted to have a look now).
> I am interested in these patches. There are too many things associated with LLVM's concept of 'generic' address space that would be nice to fully avoid with a non-0 stack.

They’re part of the repositories here:

https://github.com/ctsrd-cheri/llvm/
https://github.com/ctsrd-cheri/clang/

I have a couple of deadlines next week and the FreeBSD DevSummit the week after, but the week after that I plan on cleaning up some things for upstreaming.  Upstreaming the SelectionDAG::getPointerAdd method and uses will reduce my diff by a lot (and remove a huge amount of copy-and-paste coding in LLVM).  I also hope to clean up the support for back ends where pointers are not integers, which is apparently of interest to some other out-of-tree consumers.  I’ll put the stack-is-not-always-AS0 patches up for review at the same time.

On the LLVM side, I add a field to the DataLayout that tells you the AS for the stack.  For our back end, we run an IR pass immediately before codegen that puts the stack back in AS0 and replaces all uses of allocas with the result of an intrinsic that we pattern match on to do the conversion.  Other back ends may wish to keep it in a non-zero AS, but for us it’s an ABI choice and so we can share code between ABIs more easily this way.

There’s nothing in this tree that’s intended to be secret or private, so anything that’s useful to others please let me know.  The main reason for not upstreaming things is that there are no in-tree consumers for most of the things that we’re doing and so little demand.

David