[mpiwg-tools] Proposal: MPI_SIZEOF not profiled

[Jeff Squyres (jsquyres)]

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/