<div class="gmail_quote">On Fri, Oct 14, 2011 at 9:55 AM, 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><div></div><div class="h5">On Thu, Oct 13, 2011 at 04:21:23PM -0400, Justin Holewinski wrote:<br>
> On Thu, Oct 13, 2011 at 4:16 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk">peter@pcc.me.uk</a>>wrote:<br>
><br>
> > 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<br>
> > 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<br>
> > example, based on<br>
> > > the code you posted below, address space 0(default) is global in CUDA,<br>
> > but<br>
> > > in OpenCL, the default address space is private. So, how does the ptx<br>
> > 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<br>
> > 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>
> > 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>
> ><br>
><br>
> This is a bit hacky in the back-end at the moment.  When I started working<br>
> with the back-end, address space 0 was already defined as global, and I have<br>
> not broken that convention yet.<br>
><br>
> Then again, the issue is not really that big of a deal, since we need to<br>
> specially handle all "stack" accesses anyway.  It doesn't really matter much<br>
> what address space is used.<br>
<br>
</div></div>What kind of special handling would be required?  And how can you<br>
always tell whether or not an access through address space 0 would<br>
be a stack access?  For example, consider the attached .ll file,<br>
which compiles to a global store here.<br></blockquote><div><br></div><div>Yes, this is currently an issue with the back-end.  The handling of stack space is definitely a hack at the moment, but I have not had the time to address it since it currently works in the typical use case.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<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>