Add compound datatypes for large integers for MPI_(MIN|MAX)LOC

[mahermanns]

Problem

Currently the following predefined compound datatype handles are defined in MPI 4.0 to be used in reductions with the MPI_(MIN|MAX)LOC operator.

MPI_FLOAT_INT
MPI_DOUBLE_INT
MPI_LONG_INT
MPI_2INT
MPI_SHORT_INT
MPI_LONG_DOUBLE_INT

What seems to be missing here are one or more compound types for integers larger than long.

Use Case:

In the performance analysis tool Scalasca, the analysis uses one-sided reductions (i.e., MPI_Accumulate) with the respective operators to determine the minimum/maximum timestamp for a given epoch and the location (i.e., rank) where this occurred.

Currently, the analysis is based on double as the datatype for timestamps and can therefore use MPI_DOUBLE_INT as the datatype. However, plans to move from double to uint64_t would have the problem that such reduction could not be used.

Proposal

Adding compound types for missing common integer values types MPI_UINT64_T_INT and MPI_INT64_T_INT to allow for integer types in those reductions.

Changes to the Text

NOTE PR has hanged for March 2023 Meeting!
https://github.com/mpi-forum/mpi-standard/pull/798

Impact on Implementations

Support for these datatypes in reductions

Impact on Users

Use of MPI_(MIN|MAX)LOC is enabled for commonly used large and fixed-size integers.

References and Pull Requests

Related Issues and PRs

Note: After some discussion in the tools working group, we decided to follow through with the smaller PR#648 for MPI 4.1 and design a value-index type creation routine (including type traits) for MPI 5.0.

Allow compound datatypes created by MPI_Type_create_struct that have a specific info key-value pair (a.k.a 'type trait') set: PR#655

The current proposal suggests the function MPI_Type_get_value_index to retrieve named and unnamed predefined types. PR#798

[mahermanns]

@wrwilliams and I discussed that it actually would also be good to have these additional compound types for MPI_UINT32_T_INT and MPI_INT32_T_INT and potentially more. This should be discussed in a larger group.

[wesbland]

I'll assume this is for 4.1 for now and we can move it later if that changes.

[jeffhammond]

This is a duplicate of #18

[jeffhammond]

The current situation with pair types is totally stupid and should be fixed not with more enumerations but with a design that actually makes sense. There should be a special pair type construction function that generates all the magic types. It can return an error for unsupported pairs.

[mahermanns]

@jeffhammond Oops ... missed that. Thanks for pointing this out. #18 does not seem to consider [U]INT(16|32|64)_T but is mentioned in the discussion, so I'd assume that those would also be considered?

... also, from your comment I get that you don't like to pursue the solution of #18 either anymore and would prefer something else. Is that correct?

[jeffhammond]

I want the language independent version of #70. No enumeration, just a function that returns predefined pair types.

[mahermanns]

Notes Dec 2, 2021: Plan here is to provide the language independent version of #70 together with an additional function along the lines of std::atomic<T>::is_lock_free for RMA atomics. A branch as the basis for the discussion is in preparation.