<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Aug 26, 2015 at 8:25 PM Matt Arsenault <<a href="mailto:Matthew.Arsenault@amd.com">Matthew.Arsenault@amd.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <div>On 08/26/2015 07:02 PM, Chandler
      Carruth via llvm-dev wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_quote"><br>
          <div>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.</div>
          <br>
        </div>
      </div>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    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 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)<br></div></blockquote><div><br></div><div>FWIW, these use cases seem really straight forward for address spaces. For example, I don't think any of my questions about the semantics apply. It seems straight forward to define a set of allowed address spaces for allocas in the data layout, and a default address space[1] for them that the optimizer could use if it creates or fuses allocas in ways that leave some ambiguity.</div><div><br></div><div>But this is very different from the idea of using an alloca with an address spaces for GC pointers to stack objects...</div><div><br></div><div>Anyways, if this kind of support of specific address space stack allocations to better utilize a diverse memory hierarchy is of interest, pursuing that makes a lot of sense to me provided we specify a good semantic model for the optimizer to follow when interacting with them...</div><div><br></div><div>-Chandler</div><div><br></div><div>[1]: I actually also really agree with Mehdi here that things like a "default" address space (and the fact that for your target "0" isn't really a great default today) are maybe more of an issue with LLVM having unfortunate legacy. I'm inclined to think we should fix LLVM to let "0" be a reasonable default for allocas to simplify the work needed in the optimizer. But i've not spent a ton of time thinking through this set of issues.</div></div></div>