search for: opencl_local

> > > > +enum OpenCLAddressSpace { > > > > + OPENCL_PRIVATE = 0, > > > > + OPENCL_GLOBAL = 1, > > > > + OPENCL_LOCAL = 2, > > > > + OPENCL_CONSTANT = 3 > > > > +}; > -----Original Message----- > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > Anton, > Would there be any issue with switching the ordering of constant and > local? Hi Micah, We'd rather...

...: Anton Lokhmotov > > Cc: cfe-dev at cs.uiuc.edu > > Subject: Re: OpenCL support > > > > Here are my comments on the second patch. > > > > > +enum OpenCLAddressSpace { > > > + OPENCL_PRIVATE = 0, > > > + OPENCL_GLOBAL = 1, > > > + OPENCL_LOCAL = 2, > > > + OPENCL_CONSTANT = 3 > > > +}; > > > > If we are going to standardise these address space numbers across > > Clang and the LLVM backends, this enum declaration should be added > > somewhere in LLVM so that the backends have access to it. Perha...

...ation 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 !{ i3...

...uk] > Sent: 04 January 2011 21:42 > To: Anton Lokhmotov > Cc: cfe-dev at cs.uiuc.edu > Subject: Re: OpenCL support > > Here are my comments on the second patch. > > > +enum OpenCLAddressSpace { > > + OPENCL_PRIVATE = 0, > > + OPENCL_GLOBAL = 1, > > + OPENCL_LOCAL = 2, > > + OPENCL_CONSTANT = 3 > > +}; > > If we are going to standardise these address space numbers across > Clang and the LLVM backends, this enum declaration should be added > somewhere in LLVM so that the backends have access to it. Perhaps a > new header file cal...

> 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...

...candale 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...

...> Cc: llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > Subject: RE: [PATCH] OpenCL support - update on keywords > > > > > > +enum OpenCLAddressSpace { > > > > > + OPENCL_PRIVATE = 0, > > > > > + OPENCL_GLOBAL = 1, > > > > > + OPENCL_LOCAL = 2, > > > > > + OPENCL_CONSTANT = 3 > > > > > +}; > > > -----Original Message----- > > From: Villmow, Micah [mailto:Micah.Villmow at amd.com] > > > > Anton, > > Would there be any issue with switching the ordering of constant >...

...Anton Lokhmotov > > Cc: cfe-dev at cs.uiuc.edu > > Subject: Re: OpenCL support > > > > Here are my comments on the second patch. > > > > > +enum OpenCLAddressSpace { > > > + OPENCL_PRIVATE = 0, > > > + OPENCL_GLOBAL = 1, > > > + OPENCL_LOCAL = 2, > > > + OPENCL_CONSTANT = 3 > > > +}; > > > > If we are going to standardise these address space numbers across > > Clang and the LLVM backends, this enum declaration should be added > > somewhere in LLVM so that the backends have access to it. Perh...

...> 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...

> -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent: Saturday, August 10, 2013 5:30 AM > To: Micah Villmow > Cc: James Courtier-Dutton; LLVM Developers Mailing List > Subject: Re: [LLVMdev] Address space extension > > > [Micah Villmow] The backends won't understand your address space > > mapping. The backends

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

> [Micah Villmow] The backends won't understand your address space mapping. The backends should expose their address spaces that they support, their sizes and their overall semantics. It should be documented just like the calling convention is documented. It is then the job of the frontend to map whatever source language address spaces are used onto the correct address spaces for the

Hello to everybody, I would like to start a discussion about a possible extension of address space concept in LLVM. The idea was born starting from this discussion in the clang mailing list (first msg: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130715/084011.html - interesting point: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130722/084499.html) where