[LLVMdev] Address space extension

[Justin Holewinski]

On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale <
michele.scandale at gmail.com> wrote:

> 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 alias analysis interface allows different implementations to be chained
together.  So I would imagine this working as follows:

(1) The AddressSpaceAliasAnalysis pass (if enabled) looks for source-level
address space metadata and sees if a definitive answer can be established
(2) If result is may-alias, then check for target-dependent address space
aliasing
(3) If result is may-alias, then chain to the next implementation (either
TBAA or a more basic alias analysis)

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.


>
> 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?
>

Most likely.  Though I don't know enough about the Alias Analysis
interfaces to say for sure.


>
> -Michele
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130812/0228216b/attachment.html>