Displaying 6 results from an estimated 6 matches for "cuda_shared".
2013 Aug 07
4
[LLVMdev] Address space extension
...lf, 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...
2013 Aug 07
0
[LLVMdev] Address space extension
> 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?
&...
2013 Aug 07
3
[LLVMdev] Address space extension
...ail.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 spac...
2013 Aug 07
0
[LLVMdev] Address space extension
...gt;
>>> 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 addre...
2013 Aug 07
0
[LLVMdev] Address space extension
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
2013 Aug 07
7
[LLVMdev] Address space extension
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