MantisBT - CMake
View Issue Details
0009615CMakeCMakepublic2009-09-29 08:102009-10-19 18:31
Martin Apel 
Brad King 
normalminoralways
closedfixed 
CMake-2-8 
 
0009615: RC1 uses xiar to link Fortran libraries unnecessarily, which causes long link times
Starting with CMake 2.8, CMake uses Intel's xiar to link static Fortran libraries, even if no ipo-option is used. This causes long link times at least on Linux. In my case the generation of a static library containing several thousand objects took about one minute instead of a few seconds with CMake 2.6.

I think CMake should only use xiar, if the ipo option is specified and use ar otherwise.
No tags attached.
Issue History
2009-09-29 08:10Martin ApelNew Issue
2009-09-29 08:48Brad KingStatusnew => assigned
2009-09-29 08:48Brad KingAssigned To => Brad King
2009-09-29 08:52Brad KingNote Added: 0017817
2009-10-01 08:42Brad KingNote Added: 0017859
2009-10-01 14:37Brad KingNote Added: 0017878
2009-10-02 13:54Brad KingNote Added: 0017909
2009-10-02 13:54Brad KingStatusassigned => closed
2009-10-02 13:54Brad KingResolutionopen => fixed
2009-10-08 06:22Alex NeundorfNote Added: 0018022
2009-10-08 06:22Alex NeundorfStatusclosed => feedback
2009-10-08 06:22Alex NeundorfResolutionfixed => reopened
2009-10-08 08:21Martin ApelNote Added: 0018023
2009-10-08 08:23Brad KingNote Added: 0018024
2009-10-19 18:31Brad KingStatusfeedback => closed
2009-10-19 18:31Brad KingResolutionreopened => fixed

Notes
(0017817)
Brad King   
2009-09-29 08:52   
A problem is how to know when the -ipo option is present. It could end up in the compiler flags through a whole bunch of places, and it will not be reliable to detect it. Instead we should have some common way to enable both -ipo and xair together. I still need to think about how.
(0017859)
Brad King   
2009-10-01 08:42   
For reference, here is the thread of discussion that caused C and C++ to start using "xiar" in the first place:

http://www.cmake.org/pipermail/cmake/2008-April/021224.html [^]

Unfortunately they reached the conclusion to use "xiar" unconditionally because the original poster happened to be using "-ipo" but didn't mention it except in passing. No one at the time realized the importance.
(0017878)
Brad King   
2009-10-01 14:37   
Also for reference, here is your thread on the mailing list that started this issue:

  http://www.cmake.org/pipermail/cmake/2009-September/032275.html [^]
(0017909)
Brad King   
2009-10-02 13:54   
The commits below create an explicit INTERPROCEDURAL_OPTIMIZATION target and directory property to enable -ipo/xiar.

Centralize language flag addition for Makefiles
/cvsroot/CMake/CMake/Source/cmMakefileExecutableTargetGenerator.cxx,v <-- Source/cmMakefileExecutableTargetGenerator.cxx
new revision: 1.65; previous revision: 1.64
/cvsroot/CMake/CMake/Source/cmMakefileLibraryTargetGenerator.cxx,v <-- Source/cmMakefileLibraryTargetGenerator.cxx
new revision: 1.81; previous revision: 1.80
/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.cxx,v <-- Source/cmMakefileTargetGenerator.cxx
new revision: 1.126; previous revision: 1.125
/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.h,v <-- Source/cmMakefileTargetGenerator.h
new revision: 1.34; previous revision: 1.33

Introduce "build feature" lookup framework
/cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v <-- Source/cmLocalGenerator.cxx
new revision: 1.319; previous revision: 1.318
/cvsroot/CMake/CMake/Source/cmLocalGenerator.h,v <-- Source/cmLocalGenerator.h
new revision: 1.119; previous revision: 1.118
/cvsroot/CMake/CMake/Source/cmMakefile.cxx,v <-- Source/cmMakefile.cxx
new revision: 1.524; previous revision: 1.523
/cvsroot/CMake/CMake/Source/cmMakefile.h,v <-- Source/cmMakefile.h
new revision: 1.262; previous revision: 1.261
/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.cxx,v <-- Source/cmMakefileTargetGenerator.cxx
new revision: 1.127; previous revision: 1.126
/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.h,v <-- Source/cmMakefileTargetGenerator.h
new revision: 1.35; previous revision: 1.34
/cvsroot/CMake/CMake/Source/cmTarget.cxx,v <-- Source/cmTarget.cxx
new revision: 1.274; previous revision: 1.273
/cvsroot/CMake/CMake/Source/cmTarget.h,v <-- Source/cmTarget.h
new revision: 1.144; previous revision: 1.143

Create INTERPROCEDURAL_OPTIMIZATION build feature
/cvsroot/CMake/CMake/Modules/Platform/Linux-Intel-C.cmake,v <-- Modules/Platform/Linux-Intel-C.cmake
new revision: 1.5; previous revision: 1.4
/cvsroot/CMake/CMake/Modules/Platform/Linux-Intel-CXX.cmake,v <-- Modules/Platform/Linux-Intel-CXX.cmake
new revision: 1.7; previous revision: 1.6
/cvsroot/CMake/CMake/Modules/Platform/Linux-Intel-Fortran.cmake,v <-- Modules/Platform/Linux-Intel-Fortran.cmake
new revision: 1.4; previous revision: 1.3
/cvsroot/CMake/CMake/Source/cmMakefile.cxx,v <-- Source/cmMakefile.cxx
new revision: 1.525; previous revision: 1.524
/cvsroot/CMake/CMake/Source/cmMakefileLibraryTargetGenerator.cxx,v <-- Source/cmMakefileLibraryTargetGenerator.cxx
new revision: 1.82; previous revision: 1.81
/cvsroot/CMake/CMake/Source/cmMakefileTargetGenerator.cxx,v <-- Source/cmMakefileTargetGenerator.cxx
new revision: 1.128; previous revision: 1.127
/cvsroot/CMake/CMake/Source/cmTarget.cxx,v <-- Source/cmTarget.cxx
new revision: 1.275; previous revision: 1.274

Test INTERPROCEDURAL_OPTIMIZATION build feature
/cvsroot/CMake/CMake/Tests/CMakeLists.txt,v <-- Tests/CMakeLists.txt
new revision: 1.120; previous revision: 1.119
/cvsroot/CMake/CMake/Tests/IPO/CMakeLists.txt,v <-- Tests/IPO/CMakeLists.txt
initial revision: 1.1
(0018022)
Alex Neundorf   
2009-10-08 06:22   
I just hit that issue too.
We have
set(CMAKE_CXX_FLAGS_RELEASE "-wd654 -wd1572 -O3 -DNDEBUG -ipo" )
for some part of the project, and this was working with cvs HEAD before that last change. Linking with xiar and the object files compiled with these flags took a long time.

In another directory we don't have -ipo as part of the compile flags, there also xiar was used for linking, and there linking was fast.

Now I updated cmake, and our libs didn't link anymore, because the static library which was created (now using ar) didn't have any symbols anymore.

Setting the new directory property makes it work again, but I don't see the advantage of not using xiar always (without -ipo it's also fast).

Alex
(0018023)
Martin Apel   
2009-10-08 08:21   
We definitively do not use IPO currently, but it was still very slow, when xiar
has been used. But this is for a library with more than 6000 objects, so this may be the difference. For us it's essential to use ar instead of xiar, because otherwise people will complain about long build times.

Martin
(0018024)
Brad King   
2009-10-08 08:23   
Okay, one of you says that xiar takes forever without -ipo, and one of you says that xiar is fast without -ipo. Which is it? Is there really that much difference between the Fortran and C++ versions?

This change did break compatibility, but only for one compiler with one flag on one platform. It was by far the simplest way to solve this problem. It also finally introduces the first real "named-feature ==> flag" mapping. Just set the INTERPROCEDURAL_OPTIMIZATION directory or target property and you get -ipo and xiar back.