It's not clear to me how this would work for targets that use the same physical address space for multiple language-specific address spaces. If a target maps both constant and global to address space 42 (for example), how would the optimizer differentiate between these two? On Wed, Aug 7, 2013 at 7:15 PM, Michele Scandale <michele.scandale at gmail.com> wrote:> On 08/08/2013 12:55 AM, Matt Arsenault wrote: > >> On 08/07/2013 03:52 PM, Michele Scandale wrote: >> >>> >>> In the opencl specification is said that the four address spaces are >>> disjoint, so my conclusion of non aliasing with the others. >>> >> In OpenCL 2.0, you can cast between the generic address space and >> global/local/private, so there's also that to consider. >> >> Thanks for correction. My reference was the opencl 1.2 specification. > > Considering the case of OpenCL 2.0 IMO we would have another address space > that contains the private, the global and the local address spaces. > > > -Michele > > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<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/8fefa6f6/attachment.html>
On 08/08/2013 01:36 AM, Justin Holewinski wrote:> It's not clear to me how this would work for targets that use the same > physical address space for multiple language-specific address spaces. > If a target maps both constant and global to address space 42 (for > example), how would the optimizer differentiate between these two? >I think that the proposal of Pete would imply that in the IR the logical address spaces are represented with addrspace modifier (3 for constant and 1 for global) so the optimizer can distinguish the two and using "address space metadata" can derive properties related to this address spaces. During the instruction selection the mapping information are used to drive the selection phase. IMO whenever possible both address spaces informations must be maintained.> > On Wed, Aug 7, 2013 at 7:15 PM, Michele Scandale > <michele.scandale at gmail.com <mailto:michele.scandale at gmail.com>> wrote: > > On 08/08/2013 12:55 AM, Matt Arsenault wrote: > > On 08/07/2013 03:52 PM, Michele Scandale wrote: > > > In the opencl specification is said that the four address > spaces are > disjoint, so my conclusion of non aliasing with the others. > > In OpenCL 2.0, you can cast between the generic address space and > global/local/private, so there's also that to consider. > > Thanks for correction. My reference was the opencl 1.2 specification. > > Considering the case of OpenCL 2.0 IMO we would have another address > space that contains the private, the global and the local address > spaces. > > > -Michele > > _________________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev > <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > > > > > -- > > Thanks, > > Justin Holewinski
On Wed, Aug 7, 2013 at 7:45 PM, Michele Scandale <michele.scandale at gmail.com> wrote:> On 08/08/2013 01:36 AM, Justin Holewinski wrote: > >> It's not clear to me how this would work for targets that use the same >> physical address space for multiple language-specific address spaces. >> If a target maps both constant and global to address space 42 (for >> example), how would the optimizer differentiate between these two? >> >> > I think that the proposal of Pete would imply that in the IR the logical > address spaces are represented with addrspace modifier (3 for constant and > 1 for global) so the optimizer can distinguish the two and using "address > space metadata" can derive properties related to this address spaces. > During the instruction selection the mapping information are used to drive > the selection phase. > > IMO whenever possible both address spaces informations must be maintained. >This worries me a bit. This would introduce language-specific processing into SelectionDAG. OpenCL maps address spaces one way, other languages map them in other ways. Currently, it is the job of the front-end to map pointers into the correct address space for the target (hence the address space map in clang). With (my understanding of) this proposal, there would be a pre-defined set of language-specific address spaces that the target would need to know about. IMO it should be the job of the front-end to do this mapping.> >> On Wed, Aug 7, 2013 at 7:15 PM, Michele Scandale >> <michele.scandale at gmail.com <mailto:michele.scandale@**gmail.com<michele.scandale at gmail.com>>> >> wrote: >> >> On 08/08/2013 12:55 AM, Matt Arsenault wrote: >> >> On 08/07/2013 03:52 PM, Michele Scandale wrote: >> >> >> In the opencl specification is said that the four address >> spaces are >> disjoint, so my conclusion of non aliasing with the others. >> >> In OpenCL 2.0, you can cast between the generic address space and >> global/local/private, so there's also that to consider. >> >> Thanks for correction. My reference was the opencl 1.2 specification. >> >> Considering the case of OpenCL 2.0 IMO we would have another address >> space that contains the private, the global and the local address >> spaces. >> >> >> -Michele >> >> ______________________________**___________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> >> http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/__**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev> >> >> <http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >> > >> >> >> >> >> -- >> >> Thanks, >> >> Justin Holewinski >> > >-- Thanks, Justin Holewinski -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130807/78e85609/attachment.html>