Deprecate MPI-3.x "_x" functions

[jsquyres]

With the addition of Embiggened "count" parameters, the MPI-3.x-style _x functions are no longer needed.

They should be deprecated (in a standalone ticket either in parallel to or after the Embiggened ticket passes), because they will have no point any more.

(this is an action item for the BigCount WG)

[dholmes-epcc-ed-ac-uk]

The ticket must take into account the discussion with JeffH, JimD, and RolfR about the polymorphic nature and usage of the MPI_Aint type in MPI.

MPI needs datatype-related functions that take MPI_Aint parameters for memory and additional functions that take MPI_Offset (or MPI_Count) for files.

The MPI_Aint type can hold absolute memory addresses necessary for working with MPI_BOTTOM as a buffer address. MPI_Offset cannot play this role (because it is only used to store integer values).

OTOH, the MPI_Offset type can hold larger integer values than MPI_Aint, when that is necessary for working with relative displacements in files that are bigger than memory. MPI_Aint cannot play this role (because it is only big enough to store integer values for displacements in memory).

That being said, if the extent of an MPI datatype is always the displacement/offset from its lower-bound to its upper-bound, then it is always an integer value for which MPI_Offset (and so is MPI_Count, by definition) is sufficiently large - it never needs the "absolute address" role provided by the MPI_Aint type. OTOH, the lower-bound might be a relative address or an absolute address (depending on how the datatype was constructed).

Thus, the MPI_Type_get_extent[_?] function(s) must be able to support both roles for lb.

MPI_Type_get_extent(MPI_Datatype datatype, MPI_Aint *lb, MPI_Aint *extent)

This variant with MPI_Aint supports a datatype that was constructed using MPI_BOTTOM, where lb is an absolute address in memory. The extent is an integer value, which must (by definition) be no bigger than memory.

MPI_Type_get_extent_x(MPI_Datatype datatype, MPI_Count *lb, MPI_Count *extent)

This variant with MPI_Count supports a datatype that was constructed without using MPI_BOTTOM but targeting a file-system that is bigger than memory, where lb is a relative address (an offset) in a file. The extent is a large integer value, which might be bigger than memory and might be too large to store in an MPI_Aint. Ideally, this variant would have used MPI_Offset instead of MPI_Count, but we are where we are.

Choices:

1. change the name of MPI_Type_get_extext_x to MPI_Type_get_extext_l to fit in with all the other _l functions for large count. This is a bad idea because the MPI_Count variant is not (just) embiggening the MPI_Aint variant, it is providing a different role (target files, not absolute memory).
2. add a new MPI_Type_get_extext_l that uses MPI_Offset. This is superfluous because we already have the _x variant with MPI_Count.
3. leave it well alone. This seems like the best approach.

[dholmes-epcc-ed-ac-uk]

Response from Rolf via email

About your choices:

1.change the name of MPI_Type_get_extext_x to MPI_Type_get_extext_l to fit in with all the other _l functions for large count. This is a bad idea because the MPI_Count variant is not (just) embiggening the MPI_Aint variant, it is providing a different role (target files, not absolute memory).

Agreed, bad idea.

2.add a new MPI_Type_get_extext_l that uses MPI_Offset. This is superfluous because we already have the _x variant with MPI_Count.

Agreed, bad idea, because there is no "int Count" Argument.

3.leave it well alone. This seems like the best approach.

Partially agreed, because for the _x Versions in the derived datatype chapter,
I would always use MPI_Count and not MPI_Offset, because one never know
for which other purpose derived datatypes may be used in the future..
The concept is not restricted to Memory and I/O.
I/O is only an example why we need to provide these _x Versions.
Therefore I prefere:

4. leave it. It is the starting point for the other _X versions.

Small diff between these two _x routines and the new ones is
that for each new one, it does not have a visible Fortran _X,
only the overloaded one,
and each existing one must get the additional overloaded interface.
As far as I understand Fortran, there will be then only one backend routine
with two different interfaces, because the backend is the same _X
routine for the explicit and for the overloaded MPI_Count routine.

Best regards
Rolf