[LLVMdev] Address space extension

[Justin Holewinski]

On Mon, Aug 12, 2013 at 1:37 PM, Michele Scandale <
michele.scandale at gmail.com> wrote:

> > I don't think you need to change any of the existing MDNode's or AA
> passes.  TBAA adds metadata because that information isn't in the IR
> itself, but your IR has the address spaces.
> >
> > Shouldn't the address space of the pointer and some additional
> information about the relationships between address spaces be enough?
>  Unless i've missed something.  This thread has gotten very large :)
>
> For targets where there is only one physical address spaces the addrspace
> modifier wont be used (as is now).
> The idea is to emit TBAA-like additional info where the logical address
> space is
> described (an identifier, properties and relationship respect to other
> address
> spaces). These metadata should be attached to load/store & co.
> instructions like
> TBAA metadata.
>
> An additional alias analysis pass (chained with the others) would then use
> these
> information to decide no-alias based on address space information:
> (a) check address space metadata
> (b) if (a) says "may alias" and target address spaces are available
> (because the
> target support them) then the we query to the target to know if two target
> address spaces are disjoint, if not says "may alias" to the rest of the
> chain.
>
> Creating a new alias info metadata independent from the TBAA will require
> some
> changes... so it may be useful to think something more general as change
> to do
> the modification only once and no more in the future :-D.
>

I agree.  It makes sense to try to design a way to attach arbitrary alias
analysis MD nodes to the AliasAnalysis::Location struct.  I just worry
about any performance implications of turning that into a SmallVector<> or
such container.  Currently, its very cheap for TBAA to check if a TBAA
metadata node exists.  If this becomes a search of a container of metadata
nodes, then compiler performance may suffer.


>
> Thanks,
>
> -Michele
>
>
>
>


-- 

Thanks,

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