In case it would help to see another open-source implementation, there exists a public branch of LLVM that parallelizes DO CONCURRENT using OpenMP. The LLVM fork and git tag that I’ve used since November is cited in the “CPU Parallelism on Perlmutter” slide at http://go.lbl.gov/just-write-fortran. The compiler work has progressed since then. I can hunt down a more up-to-date branch if anyone is interested.
Damian On Sun, Jan 26, 2025 at 02:10 Tobias Burnus <tbur...@baylibre.com> wrote: > Hi, > > John Campbell wrote: > > Would it be easier to consider "DO CONCURRENT with LOCAL / LOCAL_INIT" > as a special case of !$OMP PARALLEL DO, so utilise this existing > implementation ? > > I think I want to handle by default a bare 'do concurrent' with a code > separate from OpenMP, but using the normal code. > > I am also not completely sure whether the semantic is exactly the same – > and whether there are issues with the current OpenMP implementation; I > would assume there are some with 'private' as there are with LOCAL when > using default-values in derived types. > > Note that I also did not see real obstacles yesterday but it requires > another couple of hours of work (it took so far 5h, ignoring the work > for what's in already). The future work would be either continuing with > the current approach or calling the existing OpenMP copy and > default-init functions (see PR for the function names), which still > would reuse parts of the current patch. > > It also requires more *testcases* for do concurrent to check that > everything is handled correctly; as the existing testcases (see patch) > show, simple code works – but trying hard enough, one finds things that > don't. > > [Converting the current/new testcases to OpenMP wouldn't harm, either. > I'd assume that some cases are mishandled there as well, esp. derived > types with default values.] > > > Regarding the semantic: I think OpenMP permits more – at least for > 'firstprivate', like polymorphic variables and allocatable components. – > For 'private', a lot of details are unspecified. – Fortran is more > restrictive but/hence has fewer unspecified parts. However, my feeling > is that the difference is more on the constraint-checking side in the > compiler and less on the actual implementation. > > (That polymorphic variables are supported in OpenMP's firstprivate was > rather underspecified until OpenMP 6.0; it is now permitted (except on > 'target'). GCC should handle it already correctly since GCC 13 (?).) > > * * * > > Regarding moving to real parallelization (out of scope for the current > patch): For 'do concurrent', I don't think that it should > unconditionally linke the OpenMP runtime library and turn every > do-concurrent loop into something that consumes all available threads of > the system. > > Thus, I was thinking in the past of providing -fdo-concurrent=… as flag > to decide how to handle it, i.e. use no thread parallization, use > OpenMP's, or … — The question is only the exact option, default, and > semantic. > > BTW: OpenMP before 6.0 did not permit any OpenMP directive on 'do > concurrent'. However, with OpenMP 6.0, '!$omp loop' is permitted, which > makes it possible to say per loop whether thread parallization should be > done or not. > > * * * > > I think permitting '!$omp loop' on do-concurrent will likely be a GCC 16 > item, while non thread-parallelizing do-concurrent should really still > become a GCC 15 feature! I think we also think about -fdo-concurrent=… > for GCC 16. > > Tobias > >
