using include statement for internal procedures

[Scott_L_]

Before I go too far down this path, I would like to assure myself there isn't a better way. I am using intel Fortran 17.1 on windows 7 and RH6 Linux. I find significant benefit in times using internal procedures. I need to use the same routines in multiple routines in multiple source files. I have put the low level routines in a source file which I then INCLUDE after the CONTAINS statement for all the high level routines where I want these low level routines to be available as internal routines. I did try the inline attribute. It seems the low level routine has to be in the same file and cannot be a module procedure in another file. I think that I am getting a better speedup with internal routines than inlining (if it is happening). This approach seems to work. If there is a cleaner way, I'd love to hear about it. thanks scott

[Steve_Lionel]

I suggest trying -ipo (/Qipo on Windows) - this is the whole-program interprocedural optimization feature. Add this option to every ifort command, and you should be able to use a module procedure and get benefits. 

Using INCLUDE works, but causes code bloat and may miss some cross-source optimization opportunities. 

[Scott_L_]

I presume the benefit for this would be more or less than same on Linux and windows so I could try it on either platform. I will try this. thanks

[Scott_L_]

The application I am building fails to link with -ipo. ifort 17.1 on Linux RH6. Is this caused by consolidating object files in to libraries? output summary: ifort as.f90 -o linux/Release/as.o -c -I ../Includes -DLINUX -assume nounderscore -names lowercase -noauto -fp-model=precise -fp-speculation=strict -fpconstant -traceback -O1 -ipo -I ../string/linux/Release -I ../xmlparser/linux/Release -module linux/Release ... ar crv linux/Release/as.lib linux/Release/as.o linux/Release/asfile.o linux/Release/coating.o linux/Release/coldhot.o a - linux/Release/as.o ifort streamgen.f90 -o linux/Release/streamgen.o -c -I ../Includes -DLINUX -assume nounderscore -names lowercase -noauto -fp-model=precise -fp-speculation=strict -fpconstant -traceback -O1 -ipo ... ifort -o ../../../bin_linux/streamgen.exe -O1 -ipo -static-intel -cxxlib -traceback linux/Release/streamgen.o ... ipo: warning #11003: no IR in object file ../as/linux/Release/as.lib; was the source file compiled with -ipo ipo: warning #11003: no IR in object file ../geometry/linux/Release/geometry.lib; was the source file compiled with -ipo ... ipo: warning #11021: unresolved stringsub_mp_terminal Referenced in /tmp/ipo_ifortC1draF.o ipo: warning #11021: unresolved datacore_mp_datawrite Referenced in /tmp/ipo_ifortC1draF.o ...

[Steve_Lionel]

It's not necessary that those libraries be compiled with -ipo unless you would like them to be included in the optimization. The unresolved module procedure references are more a concern for me.

[Scott_L_]

The source code for all these libraries were compiled with -ipo. as .f90 is compiled with -ipo and added to the library as.lib to be linked with higher level executables with the hope interprocedural optimization would be done. I wonder if the ar command does not include the IR information when putting the object files in the library. ifort as.f90 -o linux/Release/as.o -c -I ../Includes -DLINUX -assume nounderscore -names lowercase -noauto -fp-model=precise -fp-speculation=strict -fpconstant -traceback -O1 -ipo -I ../string/linux/Release -I ../xmlparser/linux/Release -module linux/Release ... ar crv linux/Release/as.lib linux/Release/as.o linux/Release/asfile.o linux/Release/coating.o linux/Release/coldhot.o a - linux/Release/as.o This was tested on Linux. The windows visual studio solution similarly builds libraries in projects to be linked to executables in other projects. If the same thing is likely to happen on windows, it would be hard to test this approach.

[Scott_L_]

Pursuing this further, I did find if I replaced the Linux ar command to build libraries with xiar command from intel fortran docs : Libraries are often created using a library manager such as xiar for Linux*/OS X* or xilib for Windows. Given a list of objects, the library manager will insert the objects into a named library to be used in subsequent link steps. That the build did not fail with -ipo on compiles and links. I did get executables out. I did get this warning: ifort -o ../../../bin_linux/acsysrun.exe -O1 -ipo -static-intel -cxxlib -traceback linux/Release/acsysrun.o linux/Release/acsysrunsubs.o ../acsyskernal/linux/Release/acsyskernal.lib ../acsys/linux/Release/acsys.lib ../acsysmodule/linux/Release/acsysmod.lib ../ansys/linux/Release/ansys.lib ../as/linux/Release/as.lib ../betafoil/linux/Release/betafoil.lib ../ch/linux/Release/ch.lib ../supertools/linux/Release/supertools.lib ../circuittools/linux/Release/circuittools.lib ../circuit/linux/Release/circuit.lib ../csvfile/linux/Release/csvfile.lib ../datatools/linux/Release/datatools.lib ../datafile/linux/Release/datafile.lib ../datatools/linux/Release/datatools.lib ../dynamite/linux/Release/dynamite.lib ../femtools/linux/Release/femtools.lib ../fem/linux/Release/fem.lib ../geometry/linux/Release/geometry.lib ../math/linux/Release/math.lib ../p783/linux/Release/p783.lib ../u023/linux/Release/u023.lib ../units/linux/Release/units.lib ../v319/linux/Release/v319.lib ../v599/linux/Release/v599.lib ../acsys/linux/Release/acsys.lib ../xmlparser/linux/Release/xmlparser.lib ../gasProps/linux/Release/gasProps.lib ../string/linux/Release/string.lib ../xmlparser_c/linux/Release/xmlparser_c.lib -L../../../bin_linux -lpthread -lzmq -lrt ipo: warning #11003: no IR in object file ../acsyskernal/linux/Release/acsyskernal.lib; was the source file compiled with -ipo this library was compiled with -ipo and built with xiar: ifort matlabcommand.f90 -o linux/Release/matlabcommand.o -c -I ../Includes -DLINUX -assume nounderscore -names lowercase -noauto -fp-model=precise -fp-speculation=strict -fpconstant -traceback -O1 -ipo -I ../xmlparser/linux/Release -I ../acsysmodule/linux/Release -I ../gasProps/linux/Release -I ../datafile/linux/Release -I ../datatools/linux/Release -I ../circuit/linux/Release -I ../dynamite/linux/Release -I ../fem/linux/Release -I ../units/linux/Release -I ../geometry/linux/Release -I ../math/linux/Release -I ../acsys/linux/Release -I ../supertools/linux/Release -I ../csvfile/linux/Release -I ../string/linux/Release -I ../ch/linux/Release -I -module linux/Release ifort: warning #10145: no action performed for file 'linux/Release' xiar crv linux/Release/acsyskernal.lib linux/Release/ch_write_command.o linux/Release/acsyscommand.o linux/Release/acsyscontrols.o linux/Release/acsys.o linux/Release/acsys_initialize.o linux/Release/acsysoutput.o linux/Release/acsysscript.o linux/Release/acsystasks.o linux/Release/acsysxml.o linux/Release/acsysprocs.o linux/Release/charange.o linux/Release/circuitconvert.o linux/Release/femcommand.o linux/Release/m_femcsv.o linux/Release/m_femtecplot.o linux/Release/matlabcommand.o linux/Release/zmq.o linux/Release/tecpl_socket.o linux/Release/tecpl.o linux/Release/tecplotcommand.o xiar: executing 'ar' a - /tmp/xiar_ipozlh5Yh/ch_write_command.o

[andrew_4619]

It sounds to me that having your common routines in modules would be more effecient but maybe I am misunderstanding the original post. Using include to "cut and paste" the same code in many places does indeed seem like code bloat as you are compiling the same code many times instead of once.