This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4 00/14] NVPTX: further porting
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Bernd Schmidt <bschmidt at redhat dot com>, gcc-patches at gcc dot gnu dot org, Dmitry Melnik <dm at ispras dot ru>
- Date: Fri, 23 Oct 2015 20:36:16 +0300 (MSK)
- Subject: Re: [gomp4 00/14] NVPTX: further porting
- Authentication-results: sourceware.org; auth=none
- References: <1445366076-16082-1-git-send-email-amonakov at ispras dot ru> <562779F9 dot 9070800 at redhat dot com> <alpine dot LNX dot 2 dot 20 dot 1510211759420 dot 23517 at monopod dot intra dot ispras dot ru> <20151022095442 dot GN478 at tucnak dot redhat dot com> <alpine dot LNX dot 2 dot 20 dot 1510221833190 dot 28723 at monopod dot intra dot ispras dot ru> <56291A01 dot 7090007 at redhat dot com> <20151023101621 dot GD478 at tucnak dot redhat dot com>
On Fri, 23 Oct 2015, Jakub Jelinek wrote:
> Thus, if .shared function local is allowed, we'd need to emit two copies of
> foo, one which assumes it is run in the teams context and one which assumes
> it is run in the parallel context. If automatic vars can be only .local,
> we are just in big trouble and I guess we really want to investigate what
> others supporting PTX/Cuda are trying to do here.
.shared is statically allocated. There's an implementation of nvptx
offloading in Clang/LLVM here https://github.com/clang-omp , they put data
that can be shared either in .shared or global memory (user configurable I
think). Not sure how they deal with recursion or uncertainty that you
describe in regards to the 'foo' function in your example.
Can you point me to other compilers implementing OpenMP offloading for PTX?
Alexander