[Patch][Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Patch][Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

Tobias Burnus-3
As found via sollve_vv: the Fortran OpenMP parser missed
'lastprivate' as permitted clause in 'distribute'.

Additionally, when copying + fortanifying the
libgomp.c*/pr66199-[3-9].c test case, I found an
issue with loops.

Standard gfortran DO loops use "while()" – probably
a legacy because very old Fortran had single tripes.
For SIMD loops, a "normal" "for" loop is used. The
middle end takes care of most semantic like adding
a '(last)private'.
For normal DO loops, the FE adds the 'private' to
the loop variable.

This patch now removes most handling from SIMD loops but
keeps it for other constructs. "!simple" means that an
auxiliary loop variable ("count.0") is used and the original
loop variable is then "j = ... count.0 ...".


Issues encountered (see PR):
- no truncation warnings (fixed, cf. PR94709)

- gfc_trans_omp_do added always a private(loopvar),
   even if an explicit 'lastprivate(loopvar)' was present
   (see PR for which test case)

- gfc_trans_omp_do [for *-7.f90, function f4] added a
   'lastprivate' to the 'simd' for:
   !$omp distribute collapse(2)
     !$omp simd collapse(2)
This confused the ME as none was added higher up; now
the ME handles all.

Once removing this from gfc_trans_omp_do,
gfortran.dg/target1.f90 failed
teams got a private(<loopvar>) which was then not repeated
at "distribute simd".
The reason is that gfc_resolve_do_iterator added it to
'teams' but 'gfc_trans_omp_do' not (no longer) to 'simd'.
Solution: Not adding it to SIMD loops.

I am not completely happy how it is done – nor am I sure
that there are no further pitholes. I also do not see a
good way to ensure that newer "something something SIMD"
directives get properly added to gfc_resolve_do_iterator.

OK for the trunk?

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter

distr-lastprivate-v2.diff (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

*ping* | Re: [Patch][Fortran] OpenMP - permit lastprivate in distribute + SIMD fixes (PR94690)

Tobias Burnus-3
OK for mainline and GCC 10?

The LASTPRIVATE part is trivial, but as C→Fortran porting
the test case revealed an SIMD issue, it is a bit longer.

Tobias

On 4/23/20 8:52 AM, Tobias Burnus wrote:

> As found via sollve_vv: the Fortran OpenMP parser missed
> 'lastprivate' as permitted clause in 'distribute'.
>
> Additionally, when copying + fortanifying the
> libgomp.c*/pr66199-[3-9].c test case, I found an
> issue with loops.
>
> Standard gfortran DO loops use "while()" – probably
> a legacy because very old Fortran had single tripes.
> For SIMD loops, a "normal" "for" loop is used. The
> middle end takes care of most semantic like adding
> a '(last)private'.
> For normal DO loops, the FE adds the 'private' to
> the loop variable.
>
> This patch now removes most handling from SIMD loops but
> keeps it for other constructs. "!simple" means that an
> auxiliary loop variable ("count.0") is used and the original
> loop variable is then "j = ... count.0 ...".
>
>
> Issues encountered (see PR):
> - no truncation warnings (fixed, cf. PR94709)
>
> - gfc_trans_omp_do added always a private(loopvar),
>   even if an explicit 'lastprivate(loopvar)' was present
>   (see PR for which test case)
>
> - gfc_trans_omp_do [for *-7.f90, function f4] added a
>   'lastprivate' to the 'simd' for:
>   !$omp distribute collapse(2)
>     !$omp simd collapse(2)
> This confused the ME as none was added higher up; now
> the ME handles all.
>
> Once removing this from gfc_trans_omp_do,
> gfortran.dg/target1.f90 failed
> teams got a private(<loopvar>) which was then not repeated
> at "distribute simd".
> The reason is that gfc_resolve_do_iterator added it to
> 'teams' but 'gfc_trans_omp_do' not (no longer) to 'simd'.
> Solution: Not adding it to SIMD loops.
>
> I am not completely happy how it is done – nor am I sure
> that there are no further pitholes. I also do not see a
> good way to ensure that newer "something something SIMD"
> directives get properly added to gfc_resolve_do_iterator.
>
> OK for the trunk?
>
> Tobias
>
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter