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