This is a big deal, Andre! Thanks for working on this patch. I have some test code that I can dig up if that’s helpful. Have you tested with nested derived type components, i.e., allocatable components that are themselves derived types that have allocatable components?
The need for this feature in one of my projects is one of two things that led me to prioritize other compilers at the end of 2023. At the time, the other missing feature was automatic parallelization of `do concurrent`, including automatic GPU offloading. Then a few months ago, the death blow that I couldn’t work around was robust support for kind type parameters. D Damian On Fri, Dec 6, 2024 at 10:13 Andre Vehreschild <ve...@gmx.de> wrote: > Hi all, > > I had to dive deeply into the issue with handling allocatable components in > derived types and to find a future proof solution. I hope do have found a > universal and flexible one now: > > For each allocatable (or pointer) component in a derived type a coarray > token > is required. While this is quite easy for the current compilation unit, it > is > very difficult to do for arbitrary compilation units or when one gets > libraries > that are not aware of coarray's needs. The approach this patch now > implements > is to delegate the evaluation of a reference into a coarray into a separate > access routine. This routine is present on every image, because it is > generated > by the compiler at the time it knows that a coarray access is done. With > external compilation units or libraries this solves the access issue, > because > each image knows how to access its own objects, but does not need a coarray > token for allocatable (or pointer) components anymore. The access on the > remote > image's object is done by the remote image itself (for the MPI > implementation in > a separate thread). Therefore it knows about the bounds of arrays, > allocation > and association state of components and can handle those. > > Furthermore is this approach faster, because it has O(1) complexity > regarding > the communication. The old approach was O(N) where N is the number of > allocatable/pointer components + array descriptors on the path of the > access. > The new approach sends a set of parameters to the remote image and gets the > desired data in return. > > At the moment the patch handles only getting of data from a remote image. > It is > split into two patchsets. The first one does some preparatory clean up, > like > stopping to add caf_get calls into the expression tree and removing them > afterwards again, where they are in the way. > > The second patch is then doing the access routine creation. Unfortunately > is > this the longer patch. I have also updated the documentation of the caf > API. I > hope to not have overlooked something. > > This is the first part of a series to rework all coarray access routines > to use > the new approach and then remove the deprecated calls. This makes things > clearer and easier to maintain, although the tree-dump now presents some > more > generated routines, which might look odd. > > Bootstrapped and regtested ok on x86_64-pc-linux-gnu / Fedora 39 and 41. > Ok for > mainline? > > I will continue working on the coarray stuff and fix upcoming bugs in the > future. > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
