<div dir="ltr">On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale <span dir="ltr"><<a href="mailto:michele.scandale@gmail.com" target="_blank">michele.scandale@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 08/12/2013 02:02 PM, Justin Holewinski wrote:<br>
> On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale <<a href="mailto:michele.scandale@gmail.com">michele.scandale@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:michele.scandale@gmail.com">michele.scandale@gmail.com</a>>> wrote:<br>
><br>
> On 08/12/2013 12:44 AM, Michele Scandale wrote:<br>
> > The idea is to extend the BasicAliasAnalysis to use addrspace modifier +<br>
> target<br>
> > information to decide aliasing based on physical address spaces and create a<br>
> > "MemorySpaceAliasAnalysis" for those case where source language level<br>
> > information may help, right?<br>
><br>
> I was looking to the AliasAnalysis infrastructure and TBAA implementation<br>
> details. The only metadata kind currently supported is the MD_tbaa, in fact<br>
> AliasAnalysis::Location has exactly one field for the TBAA tag.<br>
><br>
> I think that deciding the aliasing based on the address space should happen<br>
> before considering type informations, so the TBAA extension would not be a<br>
> general solution.<br>
><br>
><br>
> I could see this going either way. You could argue that address space<br>
> information is a part of the type system (e.g. a "__local float*" cannot alias a<br>
> "__global float *") for the source-level aliasing information, and not part of<br>
> the type system for target-dependent address space checks (e.g. in PTX, address<br>
> space 1 cannot alias address space 2). I do not have a strong preference either<br>
> way. Though I agree from a performance standpoint that checking for address<br>
> space aliasing would be cheaper than checking for type-based aliasing.<br>
<br>
</div>I was wondering about the case where different types may alias, but not<br>
different address spaces. Maybe this can be handled encoding as type only the<br>
address space information.<br></blockquote><div><br></div><div>The alias analysis interface allows different implementations to be chained together. So I would imagine this working as follows:</div><div><br></div><div>(1) The AddressSpaceAliasAnalysis pass (if enabled) looks for source-level address space metadata and sees if a definitive answer can be established</div>
<div>(2) If result is may-alias, then check for target-dependent address space aliasing</div><div>(3) If result is may-alias, then chain to the next implementation (either TBAA or a more basic alias analysis)</div><div><br>
</div><div>This way, you get the address space fast-path and users do not pay the cost of address space alias analysis if they don't want it. And you can still take advantage of TBAA without modifying it.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The check on the target address space property should be still performed as fast<br>
way to decide the aliasing for those target with physical disjoint address spaces.<br>
<div class="im"><br>
><br>
> Actually how a new independent alias analysis based on metadata (like TBAA, so<br>
> attached to load/store & co. instructions) can be implemented?<br>
><br>
><br>
> There is an interface for AliasAnalysis. See TypeBasedAliasAnalysis.cpp for<br>
> TBAA implementation.<br>
<br>
</div>Yes I know that, but my question is due to the fact that AliasAnalysis::Location<br>
has only one field reserved for TBAA tag. If I would like to encode another<br>
metadata that is used by another AliasAnalysis I need to extend the Location<br>
structure and the functions that compute Locations for various kind of<br>
instruction and then also extend the propagation of this information in the<br>
optimizer. Is this the correct way?<br></blockquote><div><br></div><div>Most likely. Though I don't know enough about the Alias Analysis interfaces to say for sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-Michele<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div></div>