[LLVMdev] Address space extension

[Pete Cooper]

On Aug 12, 2013, at 6:52 AM, Michele Scandale <michele.scandale at gmail.com> wrote:

> On 08/12/2013 02:34 PM, Justin Holewinski wrote:
>> On Mon, Aug 12, 2013 at 8:24 AM, Michele Scandale <michele.scandale at gmail.com
>> <mailto: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>
>>> <mailto: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.
>> 
> 
> This is more or less the same kind of solution I thought: the only difference is
> that (2) would be integrated as a part of (1), and checked before (1).
> 
>> 
>>    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.
> 
> Thus to implement the AddressSpaceAliasAnalysis we need all these kind of
> modification. Do you think would be fine to make these modification introducing
> the ASAA tags or would be better to extend this so to be able to handle generic
> AA infos (introducing a specific kind MDNode to work as container for various
> metadata used by AA passes)?
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 :)

Thanks,
Pete
> 
> Thanks,
> -Michele
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev