6 ms·

This is part of llvm trunk (upcoming 3.9 release) now: http://llvm.org/docs/CompileCudaWithLLVM.html http://llvm.org/docs/CompileCudaWithLLVM.html

by namtrac 10y ago

svensken 10y ago
Thanks for the link! Pretty exciting stuff. Can anyone comment on the following quote: The list below shows some of the more important optimizations for GPUs... A few of them have not been upstreamed due to lack of a customizable target-independent optimization pipeline. So the LLVM version of gpucc will be incomplete? Will there be a release of the original stand-alone gpucc?
- wujingyue 10y ago
  Thanks for your interest, and hope you like it! Yes, it is currently incomplete, but I'd say at least 80% of the optimizations are upstreamed already. Also, folks in the LLVM community are actively working on that. For example, Justin Lebar recently pushed http://reviews.llvm.org/D18626 http://reviews.llvm.org/D18626 that added the speculative execution pass to -O3. Regarding performance, one thing worth noting is that missing one optimization does not necessarily cause significant slowdown on the benchmarks you care about. For example, the memory-space alias analysis only noticeably affects one benchmark in the Rodinia benchmark suite. Regarding your second question, the short answer is no. The Clang/LLVM version uses a different architecture (as mentioned in http://wujingyue.com/docs/gpucc-talk.pdf http://wujingyue.com/docs/gpucc-talk.pdf) from the internal version. The LLVM version offers better functionality and compilation time, and is much easier to maintain and improve in the future. It would cost even more effort to upstream the internal version than to make all optimizations work with the new architecture.
  - svensken 10y ago
    Thanks for the clarification! It's always a pleasure to get a direct response from the first author on something as awesome as this. I'm definitely subscribing to the llvm-dev list[1] in case any discussion on this continues there. There's also the llvm-commits, clang-dev, and clang-commits lists as well, but llvm-dev kinda seems like the right place for this. Gpucc in LLVM is definitely a breath of fresh air for all of us nvcc users. To get to see some compiler internals for cuda, it feels like Christmas. A big thanks from me for all the upstreaming effort! 1: http://lists.llvm.org/mailman/listinfo/llvm-dev http://lists.llvm.org/mailman/listinfo/llvm-dev
  - jlebar 10y ago
    In fact I think at the moment almost everything, other than the memory-space alias analysis and a few pass tuning tweaks, is in. I know the former will be difficult to land, and I suspect the latter may be as well. I don't have a lot of benchmarks at the moment, so I can't say how important they are. And it of course depends on what you're doing. clang/llvm's CUDA implementation shares most of the backend with gpucc, but it's an entirely new front-end. The front-end works for tensorflow, eigen, and thrust, but I suspect if you try hard enough you'll be able to find something nvcc accepts that we can't compile. At the moment we're pretty focused on making it work well for Tensorflow.
ashitlerferad 10y ago
If only it didn't still need the proprietary CUDA SDK.
- wujingyue 10y ago
  That is a very valid concern and a key motivation for the proposed StreamExecutor project (http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.h...).
m_mueller 10y ago
Looking forward to a CUDA Fortran frontend for this. Does it exist already?
- Annatar 10y ago
  No idea, but I do know that the PGI group has had a working CUDA Fortran compiler since 2013: http://www.pgroup.com/doc/pgicudaforug.pdf http://www.pgroup.com/doc/pgicudaforug.pdf One could take one's Fortran code and simply recompile it with their compiler to run on the Nvidia GPU's. The compiler would perform automatic parallelization. Wild stuff.
  - m_mueller 10y ago
    I'm aware of that, it's the main GPU compiler I'm using currently. But I have to say, PGI only has limited resources and it would be very cool if there'd be a second player in town, especially if it's one of the big five. Btw. I'm working on something that's geared towards pretty much exactly what you're talking about. My stretch goal is fully automatic GPU parallelization for data parallel Fortran code [1]. [1] https://github.com/muellermichel/Hybrid-Fortran https://github.com/muellermichel/Hybrid-Fortran

This is part of llvm trunk (upcoming 3.9 release) now: http://llvm.org/docs/CompileCudaWithLLVM.html http://llvm.org/docs/CompileCudaWithLLVM.html

by namtrac 10y ago

This is part of llvm trunk (upcoming 3.9 release) now: http://llvm.org/docs/CompileCudaWithLLVM.html http://llvm.org/docs/CompileCudaWithLLVM.html

svensken 10y ago

Thanks for the link! Pretty exciting stuff. Can anyone comment on the following quote: The list below shows some of the more important optimizations for GPUs... A few of them have not been upstreamed due to lack of a customizable target-independent optimization pipeline. So the LLVM version of gpucc will be incomplete? Will there be a release of the original stand-alone gpucc?

wujingyue 10y ago
Thanks for your interest, and hope you like it! Yes, it is currently incomplete, but I'd say at least 80% of the optimizations are upstreamed already. Also, folks in the LLVM community are actively working on that. For example, Justin Lebar recently pushed http://reviews.llvm.org/D18626 http://reviews.llvm.org/D18626 that added the speculative execution pass to -O3. Regarding performance, one thing worth noting is that missing one optimization does not necessarily cause significant slowdown on the benchmarks you care about. For example, the memory-space alias analysis only noticeably affects one benchmark in the Rodinia benchmark suite. Regarding your second question, the short answer is no. The Clang/LLVM version uses a different architecture (as mentioned in http://wujingyue.com/docs/gpucc-talk.pdf http://wujingyue.com/docs/gpucc-talk.pdf) from the internal version. The LLVM version offers better functionality and compilation time, and is much easier to maintain and improve in the future. It would cost even more effort to upstream the internal version than to make all optimizations work with the new architecture.
- svensken 10y ago
  Thanks for the clarification! It's always a pleasure to get a direct response from the first author on something as awesome as this. I'm definitely subscribing to the llvm-dev list[1] in case any discussion on this continues there. There's also the llvm-commits, clang-dev, and clang-commits lists as well, but llvm-dev kinda seems like the right place for this. Gpucc in LLVM is definitely a breath of fresh air for all of us nvcc users. To get to see some compiler internals for cuda, it feels like Christmas. A big thanks from me for all the upstreaming effort! 1: http://lists.llvm.org/mailman/listinfo/llvm-dev http://lists.llvm.org/mailman/listinfo/llvm-dev
- jlebar 10y ago
  In fact I think at the moment almost everything, other than the memory-space alias analysis and a few pass tuning tweaks, is in. I know the former will be difficult to land, and I suspect the latter may be as well. I don't have a lot of benchmarks at the moment, so I can't say how important they are. And it of course depends on what you're doing. clang/llvm's CUDA implementation shares most of the backend with gpucc, but it's an entirely new front-end. The front-end works for tensorflow, eigen, and thrust, but I suspect if you try hard enough you'll be able to find something nvcc accepts that we can't compile. At the moment we're pretty focused on making it work well for Tensorflow.

ashitlerferad 10y ago

If only it didn't still need the proprietary CUDA SDK.

wujingyue 10y ago
That is a very valid concern and a key motivation for the proposed StreamExecutor project (http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.html http://lists.llvm.org/pipermail/llvm-dev/2016-March/096576.h...).

m_mueller 10y ago

Looking forward to a CUDA Fortran frontend for this. Does it exist already?

Annatar 10y ago
No idea, but I do know that the PGI group has had a working CUDA Fortran compiler since 2013: http://www.pgroup.com/doc/pgicudaforug.pdf http://www.pgroup.com/doc/pgicudaforug.pdf One could take one's Fortran code and simply recompile it with their compiler to run on the Nvidia GPU's. The compiler would perform automatic parallelization. Wild stuff.
- m_mueller 10y ago
  I'm aware of that, it's the main GPU compiler I'm using currently. But I have to say, PGI only has limited resources and it would be very cool if there'd be a second player in town, especially if it's one of the big five. Btw. I'm working on something that's geared towards pretty much exactly what you're talking about. My stretch goal is fully automatic GPU parallelization for data parallel Fortran code [1]. [1] https://github.com/muellermichel/Hybrid-Fortran https://github.com/muellermichel/Hybrid-Fortran