[LLVMdev] Address space extension

[Michele Scandale]

On 08/12/2013 02:02 PM, Justin Holewinski wrote:
> On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale <michele.scandale at gmail.com
> <mailto:michele.scandale at gmail.com>> wrote:
> 
>     On 08/12/2013 12:44 AM, Michele Scandale wrote:
>     > The idea is to extend the BasicAliasAnalysis to use addrspace modifier +
>     target
>     > information to decide aliasing based on physical address spaces and create a
>     > "MemorySpaceAliasAnalysis" for those case where source language level
>     > information may help, right?
> 
>     I was looking to the AliasAnalysis infrastructure and TBAA implementation
>     details. The only metadata kind currently supported is the MD_tbaa, in fact
>     AliasAnalysis::Location has exactly one field for the TBAA tag.
> 
>     I think that deciding the aliasing based on the address space should happen
>     before considering type informations, so the TBAA extension would not be a
>     general solution.
> 
> 
> I could see this going either way.  You could argue that address space
> information is a part of the type system (e.g. a "__local float*" cannot alias a
> "__global float *") for the source-level aliasing information, and not part of
> the type system for target-dependent address space checks (e.g. in PTX, address
> space 1 cannot alias address space 2).  I do not have a strong preference either
> way.  Though I agree from a performance standpoint that checking for address
> space aliasing would be cheaper than checking for type-based aliasing.

I was wondering about the case where different types may alias, but not
different address spaces. Maybe this can be handled encoding as type only the
address space information.

The check on the target address space property should be still performed as fast
way to decide the aliasing for those target with physical disjoint address spaces.

> 
>     Actually how a new independent alias analysis based on metadata (like TBAA, so
>     attached to load/store & co. instructions) can be implemented?
> 
> 
> There is an interface for AliasAnalysis.  See TypeBasedAliasAnalysis.cpp for
> TBAA implementation.

Yes I know that, but my question is due to the fact that AliasAnalysis::Location
has only one field reserved for TBAA tag. If I would like to encode another
metadata that is used by another AliasAnalysis I need to extend the Location
structure and the functions that compute Locations for various kind of
instruction and then also extend the propagation of this information in the
optimizer. Is this the correct way?

-Michele