Andre, have you tested this with the tests in OpenCoarrays suite?

I ask since this touches coarray things.

Jerry

On 12/16/24 1:58 AM, Andre Vehreschild 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

Reply via email to