Stack in a non-zero address space?

Hi,

We're currently looking at moving our stack out of the address space that contains the heap and globals (and, actually moving those into separate address spaces, but that seems easier). Currently, however, there seems to be an assumption that alloca instructions always return a pointer into address space 0, and the verifier enforces this.

Is anyone else encountering this problem? Are there any assumption in optimisers that rely on it?

David

Hi,

We're currently looking at moving our stack out of the address space that contains the heap and globals (and, actually moving those into separate address spaces, but that seems easier). Currently, however, there seems to be an assumption that alloca instructions always return a pointer into address space 0, and the verifier enforces this.

Yes, alloca returning 0 address space that is specified in the LangRef. I initially expected OpenCL local variables work by alloca'ing a nondefault address space, but instead it creates globals; e.g. kernel void foo() { local int bar[256];} declares @foo.bar. Would that work for you? If you only care about the stack being in a separate address space, would it be easier to move your heap and globals into a different address space and leave alloca as 0?

Is anyone else encountering this problem? Are there any assumption in optimisers that rely on it?

There are a lot of places left that aren't specifically getting the address space of the relevant pointer (though most of the cases I care about are fixed), and many of those are specifically for the case of alloca. AFAIK none of them really care that the address space is 0, it just isn't checked and the default is used. I have some patches that fix many of them in an effort to get rid of the default address space arguments.

-Matt