On 08/11/2013 08:41 AM, Micah Villmow wrote:> How about this as a solution. > > Add one hook into TargetInstrInfo, and one into TargetISelLowering. > > 1) getAddressSpaceRelation(unsigned AS1, unsigned AS2) - Returns either disjoint, subset, superset, equal. Function defaults to equal. > 2) isAddressSpaceSupported(unsigned AS) - Returns true if supported, false otherwise. Function defaults to false for all non-zero AS. > > These could be used by IR passes to optimized(#1) and legalization(#2). It requires no changes by backends that do not want to support multiple address spaces and extremely minimal and reasonable support by backends that do. On a plus side, it also requires no IR/Module changes.To know if two address spaces are disjoint for alias analysis purpose, it's more effective to know if in the source language the property holds or not, because as said two disjoint address spaces in the abstract model (like the one defined by OpenCL) can be implemented in the same physical address space in separated regions, so asking to the target wont produce the correct answer for all the targets (see X86 or whatever 'classical' processor with one address space)! -Michele
On Sun, Aug 11, 2013 at 5:49 AM, Michele Scandale < michele.scandale at gmail.com> wrote:> On 08/11/2013 08:41 AM, Micah Villmow wrote: > > How about this as a solution. > > > > Add one hook into TargetInstrInfo, and one into TargetISelLowering. > > > > 1) getAddressSpaceRelation(unsigned AS1, unsigned AS2) - Returns either > disjoint, subset, superset, equal. Function defaults to equal. > > 2) isAddressSpaceSupported(unsigned AS) - Returns true if supported, > false otherwise. Function defaults to false for all non-zero AS. > > > > These could be used by IR passes to optimized(#1) and legalization(#2). > It requires no changes by backends that do not want to support multiple > address spaces and extremely minimal and reasonable support by backends > that do. On a plus side, it also requires no IR/Module changes. > > To know if two address spaces are disjoint for alias analysis purpose, > it's more > effective to know if in the source language the property holds or not, > because > as said two disjoint address spaces in the abstract model (like the one > defined > by OpenCL) can be implemented in the same physical address space in > separated > regions, so asking to the target wont produce the correct answer for all > the > targets (see X86 or whatever 'classical' processor with one address space)! >Which is why I believe metadata is the right approach here. The physical address space mapping can be left as a part of the IR as it is now; the IR is target-dependent anyway and the metadata should not be needed for correctness. Then you can attach metadata to the IR that assigns language-specific semantics to the IR. If the metadata doesn't exist, or is stripped out, the optimizers have to assume aliasing. This metadata doesn't need to be language-specific. As mentioned earlier in the thread, it can just be mapping that assigns a logical address space to loads/stores, and defines which address spaces overlap. Maybe to avoid confusion, instead of calling them address spaces, we could call them address regions or something like that. Just so they're not confused with LLVM IR address spaces. This combined with Micah's proposal for the two new hooks should handle all of the use-cases. An optimizer can first look at the physical address spaces. If they are different and the target states that they do not alias, then they do not alias. This would handle aliasing for the case of generic IR. But if they may alias due to the address space information (e.g. always for X86), then the optimizer can look for metadata created by the front-end (e.g. clang OpenCL) and use that to see if aliasing is possible. In the case of OpenCL, the metadata would say aliasing is not possible between private and local memory. So even if the LLVM IR address spaces are the same, the optimizer will know that aliasing is not possible. Any I missing something here?> > -Michele > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130811/04b68d3b/attachment.html>
On 08/11/2013 10:38 PM, Justin Holewinski wrote:> On Sun, Aug 11, 2013 at 5:49 AM, Michele Scandale <michele.scandale at gmail.com > <mailto:michele.scandale at gmail.com>> wrote: > > On 08/11/2013 08:41 AM, Micah Villmow wrote: > > How about this as a solution. > > > > Add one hook into TargetInstrInfo, and one into TargetISelLowering. > > > > 1) getAddressSpaceRelation(unsigned AS1, unsigned AS2) - Returns either > disjoint, subset, superset, equal. Function defaults to equal. > > 2) isAddressSpaceSupported(unsigned AS) - Returns true if supported, false > otherwise. Function defaults to false for all non-zero AS. > > > > These could be used by IR passes to optimized(#1) and legalization(#2). It > requires no changes by backends that do not want to support multiple address > spaces and extremely minimal and reasonable support by backends that do. On > a plus side, it also requires no IR/Module changes. > > To know if two address spaces are disjoint for alias analysis purpose, it's more > effective to know if in the source language the property holds or not, because > as said two disjoint address spaces in the abstract model (like the one defined > by OpenCL) can be implemented in the same physical address space in separated > regions, so asking to the target wont produce the correct answer for all the > targets (see X86 or whatever 'classical' processor with one address space)! > > > Which is why I believe metadata is the right approach here. The physical > address space mapping can be left as a part of the IR as it is now; the IR is > target-dependent anyway and the metadata should not be needed for correctness. > Then you can attach metadata to the IR that assigns language-specific semantics > to the IR. If the metadata doesn't exist, or is stripped out, the optimizers > have to assume aliasing. This metadata doesn't need to be language-specific. > As mentioned earlier in the thread, it can just be mapping that assigns a > logical address space to loads/stores, and defines which address spaces overlap. > Maybe to avoid confusion, instead of calling them address spaces, we could call > them address regions or something like that. Just so they're not confused with > LLVM IR address spaces. > > This combined with Micah's proposal for the two new hooks should handle all of > the use-cases. An optimizer can first look at the physical address spaces. If > they are different and the target states that they do not alias, then they do > not alias. This would handle aliasing for the case of generic IR. But if they > may alias due to the address space information (e.g. always for X86), then the > optimizer can look for metadata created by the front-end (e.g. clang OpenCL) and > use that to see if aliasing is possible. In the case of OpenCL, the metadata > would say aliasing is not possible between private and local memory. So even if > the LLVM IR address spaces are the same, the optimizer will know that aliasing > is not possible. > > Any I missing something here?Now it's clear and I'm confident it will be fine. So the addrspace modifier semantic will be the current one (so target address spaces). 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? Thanks. -Michele