<div class="gmail_quote">On Thu, Oct 13, 2011 at 4:16 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Oct 13, 2011 at 06:59:47PM +0000, Villmow, Micah wrote:<br>
> Justin,<br>
>  Out of these options, I would take the metadata approach for AA support.<br>
><br>
> This doesn't solve the problem of different frontend/backends choosing different<br>
> address space representations for the same language, but is the correct<br>
> approach for providing extra information to the optimizations.<br>
><br>
> The issue about memory spaces in general is a little different. For example, based on<br>
> the code you posted below, address space 0(default) is global in CUDA, but<br>
> in OpenCL, the default address space is private. So, how does the ptx backend<br>
> handle the differences? I think this is problematic as address spaces<br>
> are language constructs and hardcoded at the frontend, but the backend needs to be<br>
> able to interpret them differently based on the source language.<br>
><br>
> One way this could be done is to have the backends have options, but then<br>
> each backend would need to implement this. I think a better approach is<br>
> to have some way to represent address spaces generically in the module.<br>
<br>
</div>Address space 0 (i.e. the default address space) should always be the<br>
address space on which the stack resides.  This is a requirement for<br>
alloca to work correctly.  So for PTX, I think that address space 0<br>
should be the local state space (but I noticed that at the moment it<br>
is the global state space, which seems wrong IMHO).<br></blockquote><div><br></div><div>This is a bit hacky in the back-end at the moment.  When I started working with the back-end, address space 0 was already defined as global, and I have not broken that convention yet.</div>
<div><br></div><div>Then again, the issue is not really that big of a deal, since we need to specially handle all "stack" accesses anyway.  It doesn't really matter much what address space is used.</div><div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
As I mentioned in my previous email, I don't think that the backend<br>
should interpret address spaces for the source language, as this<br>
places too much language-specific functionality in the backend.<br>
<br>
The situation regarding default address spaces in CUDA is more<br>
complex, but suffice it to say that there is usually no such thing<br>
as a "default" address space in CUDA, because the language does not<br>
contain support for address space qualified pointer types (only address<br>
space qualified declarations).  NVIDIA's CUDA compiler, nvopencc,<br>
determines the correct address space for each pointer using type<br>
inference (there is an explanation of nvopencc's algorithm in the<br>
src/doc/ssa_memory_space.txt file in the nvopencc distribution).<br>
Our compiler should eventually contain a similar algorithm.<br>
<br>
Thanks,<br>
<font color="#888888">--<br>
Peter<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div><br>