[Mpi3-tools] [MPI3 Fortran] MPI 3.0: Fortran 2008 interface - issue with the LOGICAL kind

[Bill Long]

On 4/22/13 3:09 AM, Tobias Burnus wrote:
> Bill Long wrote:
>>> 2) The Fortran implementation will take the performance penalty of using
>>> a wrapper routine to perform the operation (discounting sophisticated
>>> IPA/WPA (interprocedural analysis/whole program analysis)). Taking this
>>> performance penalty is common but not universal.
>>>
>>
>> I agree there will be call overhead for the user who accesses MPI
>> through the include file mechanism, unless, as you say, there is a
>> sophisticated IPA/WPA mode in the compiler.  However, the compiler
>> does not have to be all that sophisticated to inline a module
>> routine.  The compiler has to know how to find the module information
>> at compile time, and could have access to all the information needed
>> to inline the wrapper.
>
> My possibly wrong impression is that only the Cray Fortran compiler does
> so. I think most (all?) other compiler have a .mod file which contains
> the interface of the procedures but not the procedure code itself.
> Hence, they do not do any inlining at this stage. Those compilers will
> presumably only do this kind of optimization with multi-file
> interprocedural optimization (IPO)/link-time optimization (LTO).
>
> That crayftn does this inlining earlier is probably also a consequence
> of (by default) storing the module-interface information in the .o file
> instead of using a separate .mod file. If one already has the .o file,
> considering IPO is more obvious than if assembler code and module
> information are separated into .mod and .o files.

The Cray compiler has a switch (-em) that causes module information to 
be put into .mod files instead of the .o file.  This was added mainly to 
accommodate dependency rules in exiting Make files.  Inlining of module 
procedures by CCE is unaffected by which method (.mod or .o) the user 
chooses.   I'm aware that some compilers are more aggressive about 
inlining than others, which is why is wrote "could have access" instead 
of "will have access" or "has access".  On the other hand, most 
compilers routinely inline intrinsics and procedures defined in 
intrinsic modules, so the technology is available to inline "known" 
routines.  There is nothing to prevent them from treating the mpi and 
mpi_f08 modules that are accessed from known locations the same way they 
treat intrinsic modules.

The key difference with module procedures (or internal procedures or 
procedures defined in the same source file)  is that there is no 
ambiguity as to what procedure is being referenced, so it is 
theoretically possible to inline on the spot. Any particular compiler 
may or may not take advantage of this. For a non-module  or submodule 
procedure or that is defined in a different file, you don't know until 
the link step what actual procedure is being referenced (unless there 
are specific compiler options to point to the desired procedure). 
Waiting until the link step requires a more "heroic" effort.

Cheers,
Bill

>
>   * * *
>
> Regarding the latest PDF, I also have two nits:
>
> *  [p.13,ll. 5-17] The example lists several directives to disable TKR
> checks. It should add the following* to the list:
>    !GCC$ ATTRIBUTES NO_ARG_CHECK
> which GCC/gfortran now supports.*
>
> * [p.17] The TS29113 reference should be updated now that it is an
> approved ISO Technical Specification. Additionally, the name has now an
> "of Fortran" in the name: "Further Interoperability of Fortran with C"
> and latest draft (FDTS) is N1942, which contains some minor changes. See
> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45136
> and ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf
>
>
> Tobias
>
> * Cf. http://gcc.gnu.org/gcc-4.9/changes.html

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101