On Wed, 21 Oct 2015, Jakub Jelinek wrote: > On Tue, Oct 20, 2015 at 09:34:23PM +0300, Alexander Monakov wrote: > > The NVPTX backend emits each functions either as .func (callable only from > > the > > device code) or as .kernel (entry point for a parallel region). OpenMP > > lowering adds "omp target entrypoint" attribute to functions outlined from > > target regions. Unlike OpenACC offloading, OpenMP offloading does not > > invoke > > such outlined functions directly, but instead passes their address to > > 'gomp_nvptx_main'. Restrict the special attribute treatment to OpenACC > > only. > > > > * config/nvptx/nvptx.c (write_as_kernel): Additionally test > > flag_openacc for "omp_target_entrypoint". [...]
> This is certainly wrong. People can use -fopenmp -fopenacc, whether > flag_openacc is set does not mean whether the particular function is > outlined openacc or openmp region. > The question is, is .kernel actually harmful, even when you invoke it > through a stub wrapper? Like, does it not work at all, or is slower than it > could be? Taking the address of a .kernel function doesn't work (for some reason it's restricted to sm_35+), and taking the address is necessary to pass it on to gomp_nvptx_main. > If it is harmful, you should use a different attribute for OpenMP and > OpenACC target entrypoints, so perhaps "omp target entrypoint" for OpenMP > ones and "acc target entrypoint" for OpenACC ones? create_omp_child_function > that adds the attribute should have the stmt for which it is created in > ctx->stmt, so you could e.g. use is_gimple_omp_oacc for that. Thanks, that should resolve the issue nicely. Alexander
