On Aug 7, 2013, at 2:07 PM, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:> On 08/07/2013 01:52 PM, Michele Scandale wrote: >> >> IMHO this information should be a plus that could be *safely* ignored when not necessary and used where it can provide an improvement in optimizations. This does not necessary mean the the middle-end (and the back-ends) must be aware of the semantic of these logical address spaces, it would be enough just to distinguish between two logically different address spaces. >> The first application I see is alias analysis: for targets that do not have different physical address spaces (e.g. X86), meaning that in the IR the 'addrspace' modifier *should* not be present, the knowledge that two pointers refers to different logical address spaces (e.g. OpenCL address spaces) can be used to decide the aliasing. >> >> > There was this patch from a long time ago that never went in to use the address spaces for alias analysis: > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129728.html > > The decision seems to be that LLVM addrspaces aren't required to not alias. I was thinking of following the suggestion to make the datalayout contain which address spaces can / cannot alias. Alternatively, the tbaa metadata might be appropriate for this, but I haven't looked at how that works.I haven’t thought about using TBAA metadata, but I think some form of metadata would be useful here. In the clang discussion (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130715/084083.html) you noted that address space 3 could be considered constant. This is a very useful piece of information in itself, and is something we should have in the metadata. I don’t know if CUDA has aliasing address spaces, but that would also be useful to consider. Something simple like this might work. Note i’m using the examples from the clang discussion, that is "1 = opencl/cuda global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda constant" !address_spaces = !{!0, !1, !2, !3} ; Address space tuple. { address space number, parent address space, additional properties } !0 = metadata !{ i32 0, !{}, !{} } !1 = metadata !{ i32 1, !0, !{} } !2 = metadata !{ i32 2, !0, !{} } !3 = metadata !{ i32 3, !0, !4 } !4 = metadata !{ “constant” } This corresponds to 3 address spaces which all are members of address space 0, but which otherwise do not alias each other. I think this is roughly how TBAA does things. You can introduce any nodes in the tree of address spaces you need to make children in the tree alias each other. Additionally, the last address space is marked as constant which could be used for optimization, e.g. LICM. The alternative to this is to put everything in LLVM code itself. Personally I think metadata is better, but were it hard coded in the LLVM code i wouldn’t argue against it. Thanks, Pete> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130807/ffa2a76d/attachment.html>
On 08/07/2013 02:34 PM, Pete Cooper wrote:> !address_spaces = !{!0, !1, !2, !3} > > ; Address space tuple. { address space number, parent address space, > additional properties } > !0 = metadata !{ i32 0, !{}, !{} } > !1 = metadata !{ i32 1, !0, !{} } > !2 = metadata !{ i32 2, !0, !{} } > !3 = metadata !{ i32 3, !0, !4 } > > !4 = metadata !{ “constant” } > > > This corresponds to 3 address spaces which all are members of address > space 0, but which otherwise do not alias each other. I think this is > roughly how TBAA does things. You can introduce any nodes in the tree > of address spaces you need to make children in the tree alias each other. > >I like that approach -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130807/901acea4/attachment.html>
> I don’t know if CUDA has aliasing address spaces, but that would also be > useful to consider. Something simple like this might work. Note i’m > using the examples from the clang discussion, that is "1 = opencl/cuda > global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda constant"You are assuming that the target device has different physical address spaces (like, PTX or R600 or TCE). What for those one with an unique address space (e.g. X86, ARM) where all opencl/cuda address spaces are mapped (correctly) to the target address space 0?> > !address_spaces = !{!0, !1, !2, !3} > > ; Address space tuple. { address space number, parent address space, > additional properties } > !0 = metadata !{ i32 0, !{}, !{} } > !1 = metadata !{ i32 1, !0, !{} } > !2 = metadata !{ i32 2, !0, !{} } > !3 = metadata !{ i32 3, !0, !4 } > > !4 = metadata !{ “constant” } > > > This corresponds to 3 address spaces which all are members of address > space 0, but which otherwise do not alias each other. I think this is > roughly how TBAA does things. You can introduce any nodes in the tree > of address spaces you need to make children in the tree alias each other. > > Additionally, the last address space is marked as constant which could > be used for optimization, e.g. LICM.You mean that 1, 2, 3 do not alias each other, but they all alias with 0, right? The address space 0 in used to represent opencl __private address space, I think it would not alias with the others... BTW, I like the approach: it allows a fine description of relationship between address spaces that can be used in the middle-end, and the frontend is responsible for the correct emission of this language specific information. That's great!
On Aug 7, 2013, at 2:54 PM, Michele Scandale <michele.scandale at gmail.com> wrote:>> I don’t know if CUDA has aliasing address spaces, but that would also be >> useful to consider. Something simple like this might work. Note i’m >> using the examples from the clang discussion, that is "1 = opencl/cuda >> global, 2 = opencl_local/cuda_shared, 3 = opencl/cuda constant" > > You are assuming that the target device has different physical address spaces (like, PTX or R600 or TCE). What for those one with an unique address space (e.g. X86, ARM) where all opencl/cuda address spaces are mapped (correctly) to the target address space 0?That seems like something only the backend needs to care about, but it is a very important thing to consider. You could extend my approach below with one more field which for each address space tells you the HW address space it maps to. Then the selection DAG builder can use that information (if it exists) to do the translation. Thats perhaps not the cleanest implementation, but it would work. I was going to suggest that an alternative is to pass this information in to the load/store instructions in the backend, but it looks like that information is already available. That is, MachinePointerInfo has a getAddrSpace() method. This could potentially allow you to optimize MachineInstrs using the same knowledge you have here, e.g., constness for addrspace(3) in MachineLICM.> >> >> !address_spaces = !{!0, !1, !2, !3} >> >> ; Address space tuple. { address space number, parent address space, >> additional properties } >> !0 = metadata !{ i32 0, !{}, !{} } >> !1 = metadata !{ i32 1, !0, !{} } >> !2 = metadata !{ i32 2, !0, !{} } >> !3 = metadata !{ i32 3, !0, !4 } >> >> !4 = metadata !{ “constant” } >> >> >> This corresponds to 3 address spaces which all are members of address >> space 0, but which otherwise do not alias each other. I think this is >> roughly how TBAA does things. You can introduce any nodes in the tree >> of address spaces you need to make children in the tree alias each other. >> >> Additionally, the last address space is marked as constant which could >> be used for optimization, e.g. LICM. > > You mean that 1, 2, 3 do not alias each other, but they all alias with 0, right? The address space 0 in used to represent opencl __private address space, I think it would not alias with the others…Yeah, thats right, i have them all alias 0. If 0 is private and doesn’t alias anything then thats even better. Potentially that means that the optimizer will be able to reorder any access to globals with any other access to the stack for example. That will really help it optimize very well.> > BTW, I like the approach: it allows a fine description of relationship between address spaces that can be used in the middle-end, and the frontend is responsible for the correct emission of this language specific information. That's great!Thanks :)>
On Wed, Aug 7, 2013 at 5:34 PM, Pete Cooper <peter_cooper at apple.com> wrote:> > On Aug 7, 2013, at 2:07 PM, Matt Arsenault <Matthew.Arsenault at amd.com> > wrote: > > On 08/07/2013 01:52 PM, Michele Scandale wrote: > > > IMHO this information should be a plus that could be *safely* ignored when > not necessary and used where it can provide an improvement in > optimizations. This does not necessary mean the the middle-end (and the > back-ends) must be aware of the semantic of these logical address spaces, > it would be enough just to distinguish between two logically different > address spaces. > The first application I see is alias analysis: for targets that do not > have different physical address spaces (e.g. X86), meaning that in the IR > the 'addrspace' modifier *should* not be present, the knowledge that two > pointers refers to different logical address spaces (e.g. OpenCL address > spaces) can be used to decide the aliasing. > > > There was this patch from a long time ago that never went in to use the > address spaces for alias analysis: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129728.html > > The decision seems to be that LLVM addrspaces aren't required to not > alias. I was thinking of following the suggestion to make the datalayout > contain which address spaces can / cannot alias. Alternatively, the tbaa > metadata might be appropriate for this, but I haven't looked at how that > works. > > I haven’t thought about using TBAA metadata, but I think some form of > metadata would be useful here. > > In the clang discussion ( > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130715/084083.html) > you noted that address space 3 could be considered constant. This is a > very useful piece of information in itself, and is something we should have > in the metadata. > > I don’t know if CUDA has aliasing address spaces, but that would also be > useful to consider. Something simple like this might work. Note i’m using > the examples from the clang discussion, that is "1 = opencl/cuda global, 2 > = opencl_local/cuda_shared, 3 = opencl/cuda constant" > >Yes, CUDA does have aliasing address spaces, but that is captured in your tree below. The generic address space (0) can represent addresses in the shared and global (local and global in OpenCL terms) address spaces.> > !address_spaces = !{!0, !1, !2, !3} > > ; Address space tuple. { address space number, parent address space, > additional properties } > !0 = metadata !{ i32 0, !{}, !{} } > !1 = metadata !{ i32 1, !0, !{} } > !2 = metadata !{ i32 2, !0, !{} } > !3 = metadata !{ i32 3, !0, !4 } > > !4 = metadata !{ “constant” } > > > This corresponds to 3 address spaces which all are members of address > space 0, but which otherwise do not alias each other. I think this is > roughly how TBAA does things. You can introduce any nodes in the tree of > address spaces you need to make children in the tree alias each other. > > Additionally, the last address space is marked as constant which could be > used for optimization, e.g. LICM. > > The alternative to this is to put everything in LLVM code itself. > Personally I think metadata is better, but were it hard coded in the LLVM > code i wouldn’t argue against it. >Perhaps I'm just missing the context of the cfe-dev thread, but are these representing the target-dependent address spaces in the IR, or a language-specific address space mapping that is used to annotate the IR?> > Thanks, > Pete > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > 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/20130807/ab140f66/attachment.html>