search for: nvopencc

...spaces in CUDA is more complex, but suffice it to say that there is usually no such thing as a "default" address space in CUDA, because the language does not contain support for address space qualified pointer types (only address space qualified declarations). NVIDIA's CUDA compiler, nvopencc, determines the correct address space for each pointer using type inference (there is an explanation of nvopencc's algorithm in the src/doc/ssa_memory_space.txt file in the nvopencc distribution). Our compiler should eventually contain a similar algorithm. Thanks, -- Peter

Dear colleagues, I'm looking if we can replace nvopencc with LLVM NVPTX in our project. It turns NVPTX won't work with the code nvopencc can handle (please see the log below). So are atomic intrinsics not supported or am I doing call in a wrong way? Thanks, - Dima. SOURCE ======== dmikushin at hp2:~> cat kernelgen_monitor.ll ; ModuleID = '...

...re > complex, but suffice it to say that there is usually no such thing > as a "default" address space in CUDA, because the language does not > contain support for address space qualified pointer types (only address > space qualified declarations). NVIDIA's CUDA compiler, nvopencc, > determines the correct address space for each pointer using type > inference (there is an explanation of nvopencc's algorithm in the > src/doc/ssa_memory_space.txt file in the nvopencc distribution). > Our compiler should eventually contain a similar algorithm. > > Thanks,...

> -----Original Message----- > From: Dmitry N. Mikushin [mailto:maemarcus at gmail.com] > Sent: Wednesday, May 16, 2012 5:44 AM > To: LLVM-Dev > Cc: Justin Holewinski > Subject: NVPTX: __iAtomicCAS support ? > > Dear colleagues, > > I'm looking if we can replace nvopencc with LLVM NVPTX in our project. > It turns NVPTX won't work with the code nvopencc can handle (please > see the log below). So are atomic intrinsics not supported or am I > doing call in a wrong way? There are really two issues here. First, the error you are seeing is because calls...

Justin, Out of these options, I would take the metadata approach for AA support. This doesn't solve the problem of different frontend/backends choosing different address space representations for the same language, but is the correct approach for providing extra information to the optimizations. The issue about memory spaces in general is a little different. For example, based on the

Hi Justin, Thanks for bringing this up, I think it's important to discuss these issues here. On Thu, Oct 13, 2011 at 09:46:28AM -0400, Justin Holewinski wrote: > It is becoming increasingly clear to me that LLVM address spaces are not the > general solution to OpenCL/CUDA memory spaces. They are a convenient hack to > get things working in the short term, but I think a more