add fixed-size Fortran MPI_LOGICAL types

[jeffhammond]

Problem

MPI_LOGICAL is standardized, but the Fortran standard provides for multiple widths of logical and at least one implementation supports this already.

The following is a portable program, if these types are defined. Today, one must either rely on the equivalent of Fortran logical and integer, which is often true but not guaranteed, or copy logical data to a temporary array of the default logical kind.

program main
    use mpi
    implicit none
    integer :: ierr
    logical(1) :: a(2)
    logical(2) :: b(2)
    logical(4) :: c(2)
    logical(8) :: d(2)
    a = [ .true. , .false. ]
    b = [ .true. , .false. ]
    c = [ .true. , .false. ]
    d = [ .true. , .false. ]
    call mpi_init(ierr)
    call mpi_allreduce(a(1),a(2),1,MPI_LOGICAL1,MPI_LOR,MPI_COMM_WORLD,ierr)
    call mpi_allreduce(b(1),b(2),1,MPI_LOGICAL2,MPI_LOR,MPI_COMM_WORLD,ierr)
    call mpi_allreduce(c(1),c(2),1,MPI_LOGICAL4,MPI_LOR,MPI_COMM_WORLD,ierr)
    call mpi_allreduce(d(1),d(2),1,MPI_LOGICAL8,MPI_LOR,MPI_COMM_WORLD,ierr)
    print*,a,b,c,d
    call mpi_finalize(ierr)
end program main

Proposal

Add fixed-size MPI_LOGICAL datatypes to the table "Optional datatypes (Fortran)" and other places, as appropriate.

Changes to the Text

Trivial

Impact on Implementations

OMPI implements these already. Other implementations would need to do the trivial work to implement them. I suspect that the hard work is in the build system detection of Fortran compiler support, not the implementation code itself.

Impact on Users

This makes it possible to write straightforward, portable programs using Fortran logical kinds.

References and Pull Requests

[dalcinl]

Additionally, add MPI_TYPECLASS_LOGICAL for use with MPI_Type_match_size.

[dalcinl]

BTW, given than MPI specifies up to MPI_INTEGER16, then maybe MPI_LOGICAL16 makes sense (this case is not covered in the example within the description).

[jeffhammond]

INTEGER*16 makes sense because int128_t exists in some form. Library implementations exist and have use cases.

LOGICAL*16 makes no sense to me. You can't even branch on it without doing a SIMD load and compare. The only reason for it to exist is implicitly when INTEGER is 16B but that won't be the default until we have native 128b systems.

I'll reserve a slot in the ABI but we should not use it now.

[dalcinl]

@jeffhammond What I meant is the following: If a Fortran compiler supports INTEGER*16, it may also support LOGICAL*16. Is there any current Fortran compiler that supports INTEGER*16 to check what about the matching LOGICAL type?

[jeffhammond]

https://gcc.gnu.org/onlinedocs/gfortran/KIND-Type-Parameters.html

I don't care if GCC supports LOGICAL*16. It's too stupid to imagine.

[dalcinl]

https://gcc.gnu.org/onlinedocs/gfortran/KIND-Type-Parameters.html

There you have.

I don't care if GCC supports LOGICAL*16. It's too stupid to imagine.

Yes, it may look stupid. However, the MPI Forum should not be in the business of contradicting compilers just for fun.
All these types are sort of optional anyway, and it is ultimately up to the MPI implementation whether to support them.
Adding MPI_LOGICAL16 to the MPI ABI now rather than later seems totally reasonable to me, given that compiler support is already available (at least in some platforms).

[jeffhammond]

we aren't contradicting compilers. INTEGER*N is not standard for any value of N. no 128b integer is defined by the standard; only 128b real is. see https://gcc.gnu.org/onlinedocs/gfortran/ISO_005fFORTRAN_005fENV.html. look for REAL128 and INT64 (note that INT128 is missing).

there are way more important things to do for Fortran than support a non-standard, never-going-to-be-standard GCC extension, and if extensions are in scope, INTEGER*16 has use cases while LOGICAL*16 does not.

like i've said, i will reserve the space in the ABI so there is never a conflict, but LOGICAL*16 is a stupid, useless, non-standard type and unless someone here can show a use case that isn't a contrived unit test, i don't think we should talk about it.

[Wee-Free-Scot]

Do you envisage users being able to use those optional types for reduction and scan operations?

Must the logical operators MPI_LAND, MPI_LOR, MPI_LXOR work with these types? (probably yes, just like MPI_LOGICAL)
Must the other predefined operators work with these types? (probably not, just like MPI_LOGICAL)

Should they be listed on p228 (MPI-4.1 section 6.9.2) at line 3, which is referenced in line 27?

If so, this is covered in the issue description text (other locations, as appropriate), but it increases the amount of implementation work -- implementations must pick suitable/reasonable reduction and scan implementation algorithms for each of these new types for all message sizes.

Are there any users/customers for this additional implementation work who could help validate the performance expectations of these operations?

[jeffhammond]

Do you envisage users being able to use those optional types for reduction and scan operations?

Yes

Must the logical operators MPI_LAND, MPI_LOR, MPI_LXOR work with these types? (probably yes, just like MPI_LOGICAL) Must the other predefined operators work with these types? (probably not, just like MPI_LOGICAL)

Yes

Should they be listed on p228 (MPI-4.1 section 6.9.2) at line 3, which is referenced in line 27?

Yes, I just accidentally put them in the list Fortran integer: instead.

If so, this is covered in the issue description text (other locations, as appropriate), but it increases the amount of implementation work -- implementations must pick suitable/reasonable reduction and scan implementation algorithms for each of these new types for all message sizes.

Any implementation that can be compiled with LOGICAL of 4- and 8-bytes already supports half of the proposed types. I am not aware of any difficulty in the other widths.

Are there any users/customers for this additional implementation work who could help validate the performance expectations of these operations?

Open MPI already supports these types and has for years, so I assume there was a user justification for them to do so. Naturally, one can evaluate whether there is cause for concern about performance with Open MPI.