I got as far as applying and regression testing version 2. I have queried around for others to look over the patch. I will scan this one.
Since you are the expert in this area, we may just have you push and let the pieces fall out. I will get back to you later today. Jerry On Fri, Dec 20, 2024, 4:37 AM Andre Vehreschild <ve...@gmx.de> wrote: > Hi all, > > pinging again. > > Please note, that attached patch is a slightly updated version. > > Regtests ok on x86_64-pc-linux-gnu. Ok for mainline? > > Regards, > Andre > > On Mon, 16 Dec 2024 10:58:22 +0100 > Andre Vehreschild <ve...@gmx.de> wrote: > > > PING! > > > > On Fri, 6 Dec 2024 19:10:08 +0100 > > 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 > > > > > > -- > > Andre Vehreschild * Email: vehre ad gmx dot de > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
