Unfortunately, the necessary restrictions on data accesses to enable parallel execution are not required to hold true in the body of a DO CONCURRENT loop by its botched specification, and neither can they be verified at compilation time. And the committee has known about these problems for many years and has refused to fix them; Fortran 2023 still has them and the topic is not going to be brought up again for Fortran 2028.
So it is possible for a conforming program to be non-parallelizable, due to holes in the default data localization rules, despite the name of the construct and the obvious intent of the long list of restrictions imposed on code in the construct.
It's an excellent essay, and the Fortran community owes you a major gratitude for promoting these issues. But surely there loops can be safely parallelized if the iterations do not interact, e.g. per-element array arithmetic, and a compiler ought to safely identify such arithmetic.
Also, isn't your employer promoting do concurrent as a method of GPU parallelization? Has this been controversial within Nvidia?
pklausler|2 years ago
So it is possible for a conforming program to be non-parallelizable, due to holes in the default data localization rules, despite the name of the construct and the obvious intent of the long list of restrictions imposed on code in the construct.
I summarized the two specific problems in https://github.com/llvm/llvm-project/blob/main/flang/docs/Do....
marshallward|2 years ago
Also, isn't your employer promoting do concurrent as a method of GPU parallelization? Has this been controversial within Nvidia?