This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Default compute dimensions (runtime)
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Nathan Sidwell <nathan at acm dot org>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Feb 2016 19:10:44 +0300 (MSK)
- Subject: Re: Default compute dimensions (runtime)
- Authentication-results: sourceware.org; auth=none
- References: <56B21D23 dot 5060209 at acm dot org>
Hello,
On Wed, 3 Feb 2016, Nathan Sidwell wrote:
> 1) extend the -fopenacc-dim=X:Y:Z syntax to allow '-' indicating a runtime
> choice. (0 also indicates that, but I thought best to have an explicit syntax
> as well).
Does it work when the user specifies one of the dimensions, so that references
to it are subject to constant folding and VRP, but leaves some other dimension
unspecified, and when eventually GOMP_OPENACC_DIM is parsed at runtime, the
runtime-specified value of the first dimension is different from what the
compiler saw, invalidating all folding and propagation?
Here:
+ /* Do some sanity checking. The CUDA API doesn't appear to
+ provide queries to determine these limits. */
+ if (default_dims[GOMP_DIM_GANG] < 1)
+ default_dims[GOMP_DIM_GANG] = 32;
+ if (default_dims[GOMP_DIM_WORKER] < 1
+ || default_dims[GOMP_DIM_WORKER] > 32)
+ default_dims[GOMP_DIM_WORKER] = 32;
+ default_dims[GOMP_DIM_VECTOR] = 32;
I don't see why you say that because cuDeviceGetAttribute provides
CU_DEVICE_ATTRIBUTE_WARP_SIZE, CU_DEVICE_ATTRIBUTE_MAX_THREADS_PER_BLOCK,
CU_DEVICE_ATTRIBUTE_MAX_GRID_DIM_X (which is not too useful for this case) and
cuFuncGetAttribute that allows to get a per-function thread limit. There's a
patch on gomp-nvptx branch that adds querying some of those to the plugin.
Alexander