[mpiwg-abi] looking for some ABI guidance

[Jeff Hammond]

Sorry, I cannot figure out how to receive these emails normally but instead
only see them because I am the list owner, and those messages were filtered
away from inbox.

If you look at mpi.h from OMPI 4.1.2, for example, you'll see things like
this:

#define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm,
ompi_mpi_comm_world)

They use this code, which contains a useful explanation.

/*
 * When initializing global pointers to Open MPI internally-defined
 * structs, some compilers warn about type-punning to incomplete
 * types.  Therefore, when full struct definitions are unavailable
 * (when not building Open MPI), cast to an opaque (void *) pointer to
 * disable any strict-aliasing optimizations.  Don't cast to (void *)
 * when building Open MPI so that we actually get the benefit of type
 * checking (because we *do* have the full type definitions available
 * when building OMPI).
 */
#if !OMPI_BUILDING
#if defined(c_plusplus) || defined(__cplusplus)
#define OMPI_PREDEFINED_GLOBAL(type, global) (static_cast<type>
(static_cast<void *> (&(global))))
#else
#define OMPI_PREDEFINED_GLOBAL(type, global) ((type) ((void *) &(global)))
#endif
#else
#define OMPI_PREDEFINED_GLOBAL(type, global) ((type) &(global))
#endif

In Open-MPI, these are link-time constants.  However, it is possible to use
incomplete struct pointers while also having compile-time constants, for
the same reason that void * p = 0xDEADBEEF; is legal C code (albeit
implementation-defined).  See
https://github.com/mpiwg-abi/abi-issues/wiki/Valid-Pointers-and-related for
details.

Jim and I also worked out that we can have compile-time constants and still
have the named (constant) handles be symbols in the SO for dlsym purposes,
if users say they want that.  I'll write that up later.

Jeff


> ---------- Forwarded message ----------
> From: "Zhou, Hui" <zhouh at anl.gov>
> To: "mpiwg-abi at lists.mpi-forum.org" <mpiwg-abi at lists.mpi-forum.org>
> Cc:
> Bcc:
> Date: Mon, 9 Jan 2023 18:22:26 +0000
> Subject: Re: looking for some ABI guidance
> We dived directly into the technical details (intptr_t vs void *).  But
> first, excuse my ignorance, how do built-in constants, e.g. MPI_INT, work
> in OpenMPI? In MPICH, those are true constants. And it is a really nice
> feature that (at least) I appreciate. We can ask users to simply print the
> handle and deduce a lot of clues on the state of their program. But the
> appreciation may stem from the fact that I am not a debugger fan. I thought
> in the proposal of standardizing ABI, we are targeting true compile-time
> constants, is it correct? Now, if they are compile-time constants, directly
> casting it as a pointer would be something to frown upon. If we are not
> directly casting but going through conversions in the compatibility layer,
> then I don't see the differences from one side (intptr_t) to the other
> (pointer).
>
> Random question (in the form of bullets, sorry):
>
>    - If we're talking about standardizing a compatibility layer, and
>    - We're talking about using pointers for MPI handle types, and
>    - Open MPI handles are pointers already, and
>    - Per Hui's description, MPICH integer handles directly correlate to
>    pointers under the covers, then
>    - Why use (u)intptr_t?
>
> I.e., MPICH already uses pointers for the underlying MPI objects, and
> they're (assumedly) typed.  Hence, it may not be much of a stretch to use
> typed pointers in the proposed compatibility layer, rather than schlupping
> everything into a (u)intptr_t.
>
> --
>
> Hui
>

-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mpi-forum.org/mailman/private/mpiwg-abi/attachments/20230118/5406b52a/attachment-0001.html>