ipo - too aggressive

[jimdempseyatthecove]

I am in the process of developing a threading toolkit and ran across a problem with the inter-procedural optimization and thought I should bring this to the forum for comment.

I am using Windows platform and Visual Studio 2005 with Intel C++. I think the problem lies within Visual Studio or possibly the Intel integrations.

The toolkit is developed as a static library in a C:\ToolkitPath\

This contains header files and source files and the build produces

C:\ToolkitPath\Debug\foo.lib
C:\ToolkitPath\Release\foo.lib
C:\ToolkitPath\x64\Debug\foo.lib
C:\ToolkitPath\x64\Release\foo.lib

And a module within the foo.lib contains a template generated function.

After building the library(s), with no errors, I copy, in this case

C:\ToolkitPath\Release\foo.lib to C:\TestLibPath\Lib\Foo.lib

and copy

C:\ToolkitPath\*.h to C:\TestIncludePath\include\*.*

Next, I create a sample application in

C:\SampleApplication\Path

with additional include paths containing C:\TestIncludePath\include and additional library paths containing C:\TestLibPath\Lib

Now here is the problem

The ipo is locating the sources to the files used to build the library (even though no paths are pointing to them) and recompiling the appropriate components to ipo_30046obj.obj (number in name varies). And then links that together with the test application plus the Foo.lib library.

There are two serious problems with this:

First off ipo should NOT be searching paths that are NOT part of the paths declarations in the build. Perhaps $(ipoPath) could be created and used for this purpose (in addition to the current application build path).

Whats happening here is the source file of one of the components of the Foo.lib is located and built using the test applications project compilation options. In this case a Debug configuration. This library file component (with the template generated function) is compiled with debug options to ipo_nnnnnnobj.obj. The Foo.lib file built as Release build contains the same component with the template generated function) with release options. Both .obj files (one as ipo_nnnnnnnobj.obj, and one inside Foo.lib) are linked into the program and both have the same named function but with different code contents (one not optimized and one optimized). The linker seeing the different contents balks at linking to .exe.

This is fraught with versioning problems. Had the test application been built on a system that was not the development system then the ipo would likely have not included the file in the inter-procedural optimizations.

Jim Dempsey

[JenniferJ]

Quoting - jimdempseyatthecove

Whats happening here is the source file of one of the components of the Foo.lib is located and built using the test applications project compilation options. In this case a Debug configuration. This library file component (with the template generated function) is compiled with debug options to ipo_nnnnnnobj.obj. The Foo.lib file built as Release build contains the same component with the template generated function) with release options. Both .obj files (one as ipo_nnnnnnnobj.obj, and one inside Foo.lib) are linked into the program and both have the same named function but with different code contents (one not optimized and one optimized). The linker seeing the different contents balks at linking to .exe.

the ipo_nnnobj.obj should be the one used for linking not the one from foo.lib. The ipo_nnnobj.obj is the combined ipo version of the function.

so is the function prototype different in Release than debug?

I guess that I probably didn't understand the problem. I'll try with a simple testcase.

Thanks,
Jennifer

[jimdempseyatthecove]

Quoting - Jennifer Jiang (Intel)

the ipo_nnnobj.obj should be the one used for linking not the one from foo.lib. The ipo_nnnobj.obj is the combined ipo version of the function.

so is the function prototype different in Release than debug?

I guess that I probably didn't understand the problem. I'll try with a simple testcase.

Thanks,
Jennifer

I dissagree.

The sources that went into foo.lib are to be sequestered from the application developer. They are sequestered by being copied to different folders.

Example:Foo.lib sources are used to build release version 1.2.3.4 whatever
The resultant Foo.lib file is copied to CurrentGoldenReleaseCodelib whatever

Test programs are to link against CurrentGoldenReleaseCodelibFoo.lib

While testers are working on the test programs the development team is working on next major version of foo.lib2.0.0.0.alpha

I do not want the test programs to build ipo files using the new sources.

I did not instruct the IDE as to how to locate the new sources (paths to new sources not in any IDE paths) yet the IDE is looking inside the .lib (obj files) to locate the path where the oldsources used to lie when the .lib was built. But that path contains a different version of the sources than the ones used to build the .obj's inside the .lib file. Linker barfs due to contents of same named routine not being the same as was in the original build.

I did not instruct the IPO to look around on the disk for the sources so it should not look around for the sources.

This is equivilent to requesting a link with

C:ABCFOO.LIB

But the IDE saying "na I won't use that one, I'll use C:XYXFOO.LIB instead"

In this case it is slightly different because IPO was the culprit and as a result the linker barfed. Had ipo not been involved, the wrong .LIB would have been linked in causing untold numbers of debugging problems due to the wrong library being linked into the test programs under the assumption that the specified library was. (Linker is linking the correct library, the one specified, ipo is misbehaving).

Jim Dempsey

[jimdempseyatthecove]

Suggestion on the ipo problem

Currently ipo is Enable/Disable (for each compiler and linker)

These options (each) should be

Disable
Enable for Project
Enable for Solution
Enable for all Solutions (found anywhere on the system)
Enable for Solutions listed in some path macro $(ipoPaths)

Further, when the Project marks a file,or Solution marks a Project, as Exclude from Build that the file(s)so marked or Projects so marked should be excluded from the ipo.

Jim Dempsey