[mpiwg-tools] Proposal: MPI_SIZEOF not profiled

[Martin Schulz]

Hi Jeff,

I agree with what you are planning to propose, I am not sure, though, the
wording is quite right, and with this I mean more the wording in the
existing standard: this sound like as if all these functions are still
interceptable in Fortran.

What if we say:

An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
PMPI_WTIME, PMPI_WTICK, MPI_SIZEOF, PMPI_SIZEOF, and the handle-conversion
functions (MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as
macros in C or allow them to be inlined.

Advice to implementors. Implementors should document which routines are
implemented as macros or are implemented so that they can be inlined. (End
of advice to implementors.)

Advice to users. If these routines are implemented as macros or are
inlined, they will not work with the MPI profiling interface. (End of
advice to users.)


Martin



________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://scalability.llnl.gov/
CASC @ Lawrence Livermore National Laboratory, Livermore, USA








On 5/16/14, 5:44 AM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com> wrote:

>Fortran and Tools WGs:
>
>(=== this is a bit urgent if we want to get this read at the Chicago
>meeting; the T-2 deadline is this upcoming Monday morning ===)
>
>We seem to have some measure of consensus on the other thread that
>MPI_SIZEOF should not be profiled.
>
>Note, however, that the Tools chapter currently mandates that PMPI_
>versions of all MPI routines must be available (including, for example,
>MPI_WTICK), but the MPI_ versions do not have to be replaceable at link
>time.  I propose adopting this convention for MPI_SIZEOF, too (i.e. we
>have to provide PMPI_SIZEOF).
>
>Does this wording work as a proposal?
>
>MPI-3.0 p20:46 through p21:5 (T&C chapter) currently reads:
>
>-----
>An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
>PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions
>(MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C.
>
>Advice to implementors. Implementors should document which routines are
>implemented as macros. (End of advice to implementors.)
>
>Advice to users. If these routines are implemented as macros, they will
>not work with the MPI profiling interface. (End of advice to users.)
>-----
>
>but should read (new text in ***):
>
>-----
>An implementation is allowed to implement MPI_WTIME, MPI_WTICK,
>PMPI_WTIME, PMPI_WTICK, and the handle-conversion functions
>(MPI_Group_f2c, etc.) in Section 17.2.4, and no others, as macros in C.
>***MPI_SIZEOF may also be inlined.***
>
>Advice to implementors. Implementors should document which routines are
>implemented as macros ***or otherwise inlined***. (End of advice to
>implementors.)
>
>Advice to users. If these routines are implemented as macros ***or
>otherwise inlined***, they will not work with the MPI profiling
>interface. (End of advice to users.)
>-----
>
>p555:31-37 (first page of the Tools chapter) currently says:
>
>-----
>1. provide a mechanism through which all of the MPI defined functions,
>except those allowed as macros (See Section 2.6.4), may be accessed with
>a name shift.  This requires, in C and Fortran, an alternate entry point
>name, with the prefix PMPI_ for each MPI function in each provided
>language binding and language support method.  For routines implemented
>as macros, it is still required that the PMPI_ version be supplied and
>work as expected, but it is not possible to replace at link time the MPI_
>version with a user-defined version.
>-----
>
>but should say
>
>-----
>1. provide a mechanism through which all of the MPI defined functions,
>except those allowed as macros ***or otherwise inlined*** (See Section
>2.6.4), may be accessed with a name shift.  This requires, in C and
>Fortran, an alternate entry point name, with the prefix PMPI_ for each
>MPI function in each provided language binding and language support
>method.  For routines implemented as macros ***or otherwise inlined***,
>it is still required that the PMPI_ version be supplied and work as
>expected, but it is not possible to replace at link time the MPI_ version
>with a user-defined version.
>-----
>
>-- 
>Jeff Squyres
>jsquyres at cisco.com
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/
>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools