[LLVMdev] Address space extension
Justin Holewinski
justin.holewinski at gmail.com
Mon Aug 12 05:02:21 PDT 2013
On Mon, Aug 12, 2013 at 6:03 AM, Michele Scandale <
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.
>
> 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.
>
> Thanks.
>
> -Michele
>
--
Thanks,
Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130812/9c439937/attachment.html>
More information about the llvm-dev
mailing list