[ was: Re: [nvptx] vector length patch series ]
On 14-12-18 20:58, Tom de Vries wrote:
>> 0004-openacc-Make-GFC-default-to-1-for-OpenACC-routine-di.patch
> If I remove this, I run into ICEs in the compiler, but I think that
> means we need to understand and fix that ICE, instead of concluding that
> we need this patch. It looks completely unrelated.
Indeed this
(0004-openacc-Make-GFC-default-to-1-for-OpenACC-routine-di.patch) patch
is unrelated to the vector length functionality.
However, it fixes a problem in the Fortran front-end which has as
consequence that C and Fortran routines look the same in
nvptx_goacc_validate_dims, which is a good thing to have.
However, the upstreaming of the patch seems to be stuck, so I've
committed an nvptx workaround patch that has the same effect, allowing
us to drop it
(0004-openacc-Make-GFC-default-to-1-for-OpenACC-routine-di.patch) from
the patch series.
Thanks,
- Tom
[nvptx] Unify C/Fortran routine handling in nvptx_goacc_validate_dims
The Fortran front-end has a bug (PR72741) that means what when
nvptx_goacc_validate_dims is called for a Fortran routine, the dims parameter
is not the same as it would have been if the function would have been called for
an equivalent C routine.
Work around this bug by overriding the dims parameter for routines, allowing the
function to handle routines in Fortran and C the same.
Build and reg-tested on x86_64 with nvptx accelerator.
2018-12-17 Tom de Vries <tdevr...@suse.de>
* config/nvptx/nvptx.c (nvptx_goacc_validate_dims): Work around Fortran
bug PR72741 by overriding dims parameter for routines.
---
gcc/config/nvptx/nvptx.c | 36 ++++++++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index 746d8bfb100..24727ad5920 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -5212,6 +5212,42 @@ nvptx_goacc_validate_dims (tree decl, int dims[], int fn_level)
else
gcc_unreachable ();
+ if (routine_p)
+ {
+ /* OpenACC routines in C arrive here with the following attributes
+ (omitting the 'omp declare target'):
+ seq : __attribute__((oacc function (0 1, 0 1, 0 1)))
+ vector: __attribute__((oacc function (0 1, 0 1, 1 0)))
+ worker: __attribute__((oacc function (0 1, 1 0, 1 0)))
+ gang : __attribute__((oacc function (1 0, 1 0, 1 0)))
+
+ If we take f.i. the oacc function attribute of the worker routine
+ (0 1, 1 0, 1 0), then:
+ - the slice (0, 1, 1) is interpreted by oacc_fn_attrib_level as
+ meaning: worker routine, that is:
+ - can't contain gang loop (0),
+ - can contain worker loop (1),
+ - can contain vector loop (1).
+ - the slice (1, 0, 0) is interpreted by oacc_validate_dims as the
+ dimensions: gang: 1, worker: 0, vector: 0.
+
+ OTOH, routines in Fortran arrive here with these attributes:
+ seq : __attribute__((oacc function (0 0, 0 0, 0 0)))
+ vector: __attribute__((oacc function (0 0, 0 0, 1 0)))
+ worker: __attribute__((oacc function (0 0, 1 0, 1 0)))
+ gang : __attribute__((oacc function (1 0, 1 0, 1 0)))
+ that is, the same as for C but with the dimensions set to 0.
+
+ This is due to a bug in the Fortran front-end: PR72741. Work around
+ this bug by forcing the dimensions to be the same in Fortran as for C,
+ to be able to handle C and Fortran routines uniformly in this
+ function. */
+ dims[GOMP_DIM_VECTOR] = fn_level > GOMP_DIM_VECTOR ? 1 : 0;
+ dims[GOMP_DIM_WORKER] = fn_level > GOMP_DIM_WORKER ? 1 : 0;
+ dims[GOMP_DIM_GANG] = fn_level > GOMP_DIM_GANG ? 1 : 0;
+ changed = true;
+ }
+
/* The vector size must be 32, unless this is a SEQ routine. */
if ((offload_region_p || oacc_default_dims_p
|| (routine_p && !routine_seq_p))
