# LLVM upstream version vs. NVVM LLVM version **URL:** \ **Category:** Development\ **Created:** [June 19, 2020, 11:06am UTC](https://numba.discourse.group/t/llvm-upstream-version-vs-nvvm-llvm-version/62 "2020-06-19T11:06:21Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![gmarkall](https://yyz2.discourse-cdn.com/free1/user_avatar/numba.discourse.group/gmarkall/32/42_2.png) [@gmarkall](https://numba.discourse.group/u/gmarkall)\ **Post date:** [June 19, 2020, 2:44pm UTC](https://numba.discourse.group/t/llvm-upstream-version-vs-nvvm-llvm-version/62/3 "2020-06-19T14:44:08Z")
> Would this make it possible for extensions like [Awkward Array](https://github.com/scikit-hep/awkward-1.0#readme) to run in `numba.cuda.jit` ed functions? This change wouldn’t do anything for extensions - the CUDA target already uses NVVM, it’s just that the pipeline is currently: Bytecode → Numba IR → LLVM IR → Optimized LLVM IR → NVVM → … and I’m suggesting making it: Bytecode → Numba IR → LLVM IR → NVVM → … NVVM is itself based on LLVM, so it also runs LLVM optimization passes - the proposed change means we only have the optimizations once, instead of the current situtation where we run them twice, first with LLVM 9 then with an earlier LLVM version inside NVVM, which causes some problems. There are other facilities we should look at to support Awkward Arrays in CUDA jitted functions - I’ve started [this topic](https://numba.discourse.group/t/making-awkward-arrays-work-in-the-cuda-target/63) for that discussion, and I hope we can make some progress there. --- _[View the full topic](https://numba.discourse.group/t/llvm-upstream-version-vs-nvvm-llvm-version/62)._