Hi all,
my long term plan was to add -fdo-concurrent=... to permit
the user to decide how to handle do-concurrent loops:
Just use it normal loop / vectorization hint, move to
some kind of thread parallelization (e.g. implied
'omp parallel do').
For offloading, I would go for '!$omp target loop',
given that OpenMP now permits !$omp (target) loop' on
do-concurrent loops. (Not yet supported in GCC; I
think new in OpenMP 6.0.)
To me it was always unclear what users expect and I fear
different users expect different thinks. (Not wanting
multiple threads, wanting as many parallel threads as
possible - only parallizing if compiler-known to be
threadsafe vs. always parallelizing.)
Thus, the idea to give the user this control.
However, we might discuss what should be the default.
* * *
Dhruv Chawla <[email protected]> wrote:
This flag causes the frontend to emit annot_expr_parallel_kind for
do-concurrent loops, bypassing the PR83064 fix which would emit
annot_expr_ivdep_kind. This flag is meant to be a temporary fix,
We had:
r0-126041-g2ca4e2c2296e9b (Oct 24, 2013)
re PR fortran/44646 ([F08] Implement DO CONCURRENT)
(gfc_trans_forall_loop): Mark those as annot_expr_ivdep_kind.
r8-4699-g34705fdc3b33df (Nov 17, 2017)
re PR fortran/83017 (DO CONCURRENT not parallelizing)
* trans-stmt.c (gfc_trans_forall_loop): Annotate DO CONCURRENT
loops with annot_expr_parallel_kind instead of just
annot_expr_ivdep_kind.
r8-7827-gbc436e10e0b892 (Apr 12, 2018)
re PR fortran/83064 (DO CONCURRENT and auto-parallelization)
* trans-stmt.c (gfc_trans_forall_loop): Use annot_expr_ivdep_kind
for annotation and remove dependence on -ftree-parallelize-loops.
I think we can discuss about what should be the default, but I
very much prefer to have a mode that doesn't use threads and
one that does - either via -ftree-parallelize-loops or via, e.g,
'omp parallel for'.
That's the reason for -fdo-concurrent=... and was something I
wanted to see from the beginning. I think the problem is that
the user intent of 'do concurrent' is rather unclear, some
might expect thread parallelization others just vectorization.
* * *
+@opindex fdoconcurrent-force-parallel
+@item -fdoconcurrent-force-parallel
+This option forces parallelization of do-concurrent loops, bypassing the
+usual validity analysis done by the compiler. This can introduce correctness
+issues, so it should be used with caution.
Fortran (here: Fortran 2023) states:
"The block of a DO CONCURRENT construct is executed for every active
combination of the index-name values. Each execution of the block is an
iteration. The executions may occur in any order."
It seems as of -fdo-concurrent= needs three modes:
1 only vectorization (ivdep)
2 parallelization with validity analysis
3 parallelization without validity analysis
plus possibly:
4 Using 'openmp-parallel' instead of -ftree-parallelize-loops
(no idea whether it really makes a difference)
5 With -fopenmp, if '!$omp (target) loop' is present, override
the 1–4 settings and use this one instead. (Note: not yet
implemented in GCC)
The Fortran semantic has no issue with ordering; thus, I think
there are two potential issues:
(A) two iterations writing to / defining the same variable
(B) other code that is not thread save (like calling a function
that uses static memory in between)
For (A), the main usage is reduction - and here Fortran 2018 added
'REDUCE' - I think when we go parallel, we at least need to support
this locality spec.
There might be additional cases that require atomics. Unfortunately,
Fortran does not provide any atomic support for non-coarrays. There is
a proposal to add one to Fortran 202Y,
https://j3-fortran.org/doc/year/26/26-116.txt
but it is not quite clear whether it is still on the agenda given
that the workplan
https://j3-fortran.org/doc/year/26/26-010r2.pdf states
has: "Add support for atomic operations in local memory = J3 recommended
item to be removed from F202Y workplan"
For (B), I think it is largely a problem of the user as 'recursive'
is the default for procedures and usual code is also threadsafe.
With OpenMP, using 'atomic' inside 'do concurrent' is permitted; I
think at least all directives that are 'pure'.
For the documentation, it makes sense to point to REDUCE and mention
the atomic pitfalls and issues with code that is (otherwise) not
threadsafe.
Thanks,
Tobias
