LLVM IR is intermediate representation (byte code) between compilation and code generation. 
Unforuntelly it doesn't directly support CUDA/OpenCL semantics and there are several incompatible
ways to treat it.
 - LibCLC is OpenCL 1.1 frontend for LLVM. It compiles OpenCL code to LLVM IR and uses LLVM IR metadata
 to represent GPU-specific constructs and provides a number of base functions as intrinsics. It also includes
 a number of backends (i.e. NVPTX64) to generate NVIDIA (PTX) and AMD intermediate representation. 
 Disadvantage: Only OpenCL 1.1 at the moment and probably slower than nvcc as NVIDIA optimizer is not a part
 of the chain.
 - POCL is OpenCL 1.2 (with elements of 2.0) which supports native CUDA backend.
 Disadvantage: Textures and atomics are not implemented yet. Seems some performance issues...
 - NVVM IR is NVIDIA subset of LLVM IR which also uses LLVM IR metadata to represent GPU constructs. However,
 it is not compatible with LibCLC and there is no OpenCL frontend available. Samples for Python and Haskell 
 are available officially.
    https://github.com/nvidia-compiler-sdk
 The sources are from 2014 and it seems not much happened since (at least in open-source world). Also, neither 
 nvcc nor othr NVIDIA tools output NVVM IR representation. There is unofficial hacks to getaccess though 
 (unclear if still working):
    https://github.com/apc-llc/nvcc-llvm-ir
 Disadvantage: The latest version of LLVM often is not supported (LLVM5 only while LLVM7 is already out). OpenCL 
 frontend is not available.
 - SPIR-V is Khronos intermediate language wich modifies LLVM IR to include primitives required from rendering (Vulkan)
 and GPU computing. It is part of OpenCL 2.1. NVIDIA also provides beta support for their Vulkan implementation, but no
 support for CUDA/OpenCL yet. More details:
    https://streamhpc.com/blog/2015-05-21/8-reasons-why-spir-v-makes-a-big-difference/
 Disadvantage: Only OpenCL-2.1 compatible frameworks (Intel), no NVIDIA support yet. AMD is currently on OpenCL-2.0 which
 uses SPIR 2.0 which is not compatible with SPIR-V. No SPIR-V to NVVM-IR converter either.

Vulkan:
 - Khronos plans to merge OpenCL in Vulkan specification later. But would NVIDIA care?
 - There is WebVK prototype. But it seems there is agreement that Vulkan will not replace WebGL
    https://floooh.github.io/2016/08/13/webgl-next.html 


Non-LLVM based solutions:
 - HIP is a part of new AMD ROCm stack. HIP is closely follows CUDA Run-time API. It provides tools to automatically
 convert CUDA code to HIP. And it provides backends to execute HIP code using CUDA framework or AMD HCC. 
    https://streamhpc.com/blog/2016-04-05/comparing-syntax-cuda-opencl-hip/
    https://rocm-documentation.readthedocs.io/en/latest/ROCm_API_References/HIP-API.html#hip-api
 * It seems bounds are supported.
 * It seems ROCm OpenCL uses standard pointers as cl_mem. This is not hte case on CUDA platform. I.e. we probably
 can use HIP to integrate CUDA library to UFO on AMD platform, but in no way on NVIDIA.
 Disadvantage: We can't easily migrate OpenCL applications. It also doesn't seem we can provide inter-operability 
 between OpenCL and CUDA/HIP on the NVIDIA platform. Still probably it is the best available solution to target
 NVIDIA and AMD GPUs and general-purpose CPUs.
 - SNUCL. Porvides two-way OpenCL/CUDA conversion by providing substitute libraries and recompiling kernels.
 Disadvantages: Last commit 2 years ago and relies on modified LLVM source tree.

DSL:
 - AnyDSL: With backends to LLVM, CUDA, OpenCL.



Questions: 
 - How it is complicated to implement OpenCL 'image' support in POCL? Can we get CUDA pointers out? And vice-versa construct
 OpenCL pointers from CUDA. GPUDirect integration?