[mpiwg-abi] MPI_Fint in the ABI

[Jeff Hammond]

selected_int_kind(R) behaves differently than you are thinking.

"The result has a value equal to the value of the kind type parameter of an integer type that represents all values n in the range −(10^R) < n < (10^R), or if no such kind type parameter is available on the processor, the result is −1. If more than one kind type parameter meets the criterion, the value returned is the one with the smallest decimal exponent range, unless there are several such values, in which case the smallest of these kind values is returned.”

selected_int_kind(0) doesn’t return the default, but the smallest supported integer kind that can represent zero, and indeed with gfortran, it is an 8-bit integer.

In any case, changing from INTEGER to something else for the handle arguments is an API change and that will only happen in new modules (and a new mpif.h if someone un-deprecates it).  I intend to pursue this for MPI 5.0, only after I have prototyped to determine that there is any benefit.  I am skeptical of the performance benefit of eliminating the conversion of non-predefined handles (pre-defined handles have a fast conversion path with the ABI).  I don’t think the usability argument is going to be sufficient to drive adoption.  We already have a hard time getting people to use MPI_F08 and it overwhelmingly superior to anything else.

Jeff


On 19. Aug 2023, at 14.03, Lisandro Dalcin <dalcinl at gmail.com> wrote:



On Sat, 19 Aug 2023 at 13:43, Jeff Hammond <jehammond at nvidia.com<mailto:jehammond at nvidia.com>> wrote:
Fortran doesn’t have an ABI across compilers but the MPI Fortran ABI is defined by the use of constants that match the C ABI, as is required. It is involves similarly required compatibility with Aint, Offset and Count.


Oh, OK, so your definition of Fortran ABI is the one that, for a given Fortran compiler, matches the C ABI.

Intel likely achieves their ILP64 support by ignoring MPI_Fint in the header and dlopen-ing the right symbol on launch. I’ll verify that later.

Well, my point is, the ILP64 support is Fortran-only. There are no provisions for C and mpi.h to interoperate with the ILP64 library.

A more expansive Fortran ABI definition that does what you propose has been considered. It represents a breaking API change and thus requires new module (and deprecated header) names.

That's why I asked for a Fortran lawyer. My limited knowledge of Fortran tells me that "integer" and "integer(kind=selected_int_kind(0))" are the same type. I fail to see the extent of the breakage, or why new module names are needed.
If the new module uses "integer(kind=MPI_HANDLE_KIND)" with MPI_HANDLE_KIND equal to selected_int_kind(0) for a standard invocation of the compiler, old code that uses plain "integer :: comm" declarations should continue to work, as long as users do not compile with -i8. For new code to work seamlessly with an ILP64 Fortran library, users have to update their Fortran code to use integer(kind=MPI_HANDLE_KIND), but in this case MPI_HANDLE_KIND is still a 32bits integer.

--
Lisandro Dalcin
============
Senior Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
http://ecrc.kaust.edu.sa/
--
mpiwg-abi mailing list
mpiwg-abi at lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpiwg-abi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-abi/attachments/20230821/78b3e748/attachment.html>