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