[LLVMdev] Address space extension

Michele Scandale michele.scandale at gmail.com
Wed Aug 7 14:54:02 PDT 2013


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




More information about the llvm-dev mailing list