[Mpi3-tools] [MPI3 Fortran] MPI function symbol naming convention for tools

[Hubert Ritzdorf]

There are (compiled) libraries and object files containing the corresponding external references to MPI_SEND, mpi_send__, mpi_send_ or mpi_send. Therefore, you cannot simply change the interface of the MPI_Send routine without breaking these libraries. You can also not simply expect that they will be recompiled.

In addition, the mpif.h include file doesn't have an interface block (and will still generate the external references above) and Fortran 90 module doesn't have an optional error argument in the interface block even if you expect that the Fortran 90 module/compiler supports some NO_ARG_CHECK attribute.
Therefore, you cannot simply change the name of the Fortran MPI_Send routine to mpi_send_f.

Hubert Ritzdorf
NEC Germany

>-----Original Message-----
>From: mpi3-fortran-bounces at lists.mpi-forum.org [mailto:mpi3-fortran-
>bounces at lists.mpi-forum.org] On Behalf Of Jeff Squyres
>Sent: Friday, June 24, 2011 4:00 PM
>To: Martin Schulz
>Cc: MPI3 Tools; MPI-3 Fortran working group
>Subject: Re: [MPI3 Fortran] MPI function symbol naming convention for tools
>
>On Jun 23, 2011, at 10:51 PM, Martin Schulz wrote:
>
>>>> I read Craig's email as if the existing interface (without using
>mpi_f08)
>>>> would get the new symbol as well. If I read you right, this is not the
>case.
>>>
>>> That *is* the case.  That's why I started my sentence with "So in one
>sense..."  :-)
>>
>> Now, I am confused - this seems to contradict the above.
>> If I compile a F77 only program that uses mpif.h and has a
>> call to MPI_Recv, which symbol(s) do I get?
>
>if (Craig's proposal is accepted) {
>  if (implementation has implemented Craig's proposal) {
>      // call this "Case A"
>      if (app uses mpif.h or "use mpi" interface) {
>         tool will find mpi_send_f
>         // ...and others listed in Craig's proposal
>      }
>      if (app uses "use mpi_f08" interface) {
>         tool will find mpi_send_f08
>         // ...and others listed in Craig's proposal
>      }
>  } else {
>      // implementation has NOT implemented Craig's proposal
>      // call this "Case B"
>      if (app uses mpif.h interface) {
>         tool will find MPI_SEND, mpi_send, mpi_send_, or mpi_send__
>      }
>      if (app uses "use mpi" interface) {
>         I doubt tools know how to find the symbols for functions
>         with choice buffers, because nothing is standardized
>         and there's (potentially) lots of function overloading
>      }
>  }
>} else {
>    // same as "Case B"
>}
>
>Keep in mind:
>
>- even if Craig's proposal is accepted, it'll take at least 6 months for
>this to become part of MPI-3
>- even if Craig's proposal becomes part of MPI-3, implementations will
>likely take a long time before they support this new stuff
>- implementations *could* support the old symbols for a while if they
>wanted to (e.g., MPI_SEND, mpi_send, mpi_send_, mpi_send__)
>
>My point: I'm not too worried about tools needing to update to get the new
>symbol conventions because a) implementations have to update, too, and b) I
>think standardized symbol conventions put the MPI spec in a better place
>for the future -- *future* tools will have an easier time than current
>tools.
>
>> Sure, the addition is not hard - the more complicated
>> part will be the routines for the optional parameters.
>> We can no longer deduce them automatically from
>> any header file and will always have to special code
>> them. Do we really need them? Why not pass a
>> STATUS_IGNORE argument?
>
>I think that's under debate at the moment.
>
>But that being said, what's the problem with testing for the optional
>arguments?  You're in a tool already, meaning that performance overhead is
>already assumed to be somewhere between (nonzero <--> high), so what's 1 or
>2 more "if" statements?
>
>>> And, more importantly, I believe there's plenty of time for existing
>tools to adapt (e.g., to add intercepting the 5th symbol) -- maybe a year
>or more.  OMPI will have a first prototype implementation soon; I imagine
>the others will follow over time (assuming that this proposal, or something
>like it, is passed into the MPI-3 spec over the course of the next 6
>months).
>>
>> In the meantime, they will be labeled as MPI 2.2 tools and will
>> work with any MPI 2.2 compliant code. As long as that still
>> works (and I see no reason why not) then I think things are fine.
>
>This is what I'm saying.
>
>>> Also note that there is no standardized nomenclature for intercepting
>"use mpi" symbols, so I'll bet you a high-quality beer that there are no
>portable tools that properly instrument "use mpi" interfaces.  OMPI's "use
>mpi" implementation, for example, *sometimes* calls the corresponding
>mpif.h symbol, but not always.  Heck, I'll even bet you another HQ beer
>that there's *no* MPI implementation that supports explicit Fortran
>interfaces for all MPI functions in its "use mpi" interfaces that has a
>corresponding interception / tracing tool -- specifically because of the
>lack of standardization of how to do it.
>>>
>>> Craig's proposal gives you a way to reliably intercept the "use mpi"
>symbols.
>>
>> Well, not quite - we still have to play the tricks for older MPIs
>> and for the parts of the codes that don't use the module. Those
>> will use the old naming convention, right?
>
>I'm not sure I can parse your statement -- it doesn't seem to be a logical
>result of my text...?
>
>The portion of my text that you were replying to was only speaking about
>the "use mpi" interface -- not mpif.h.  See above for discussions about
>mpif.h.
>
>As for "use mpi": there is no naming convention for "use mpi" symbols right
>now.  Therefore, there's no commonality between MPI implementations.  Are
>there any tools that reliably, portably intercept all "use mpi" symbols
>right now?  I was under the impression that there were none, but perhaps
>I'm wrong...?
>
>--
>Jeff Squyres
>jsquyres at cisco.com
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
>_______________________________________________
>mpi3-fortran mailing list
>mpi3-fortran at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>
>
> Click
>https://www.mailcontrol.com/sr/usm!Nh46RiHTndxI!oX7UqpixUKymCqxTDACcy67S9iI
>adHPAjIZPDMvmfJgurQ+nNutHdm6V!yDEGNPdlyNkQ==  to report this email as spam.