IPO: Linking libraries built with ICC with application built with GCC

[govind_s_1]

I am using icc version 13.1.0 (gcc version 4.6.0 compatibility) with gcc version 4.6.3 on Ubuntu 12.04.2.

I have a set of static libraries, say lib1.a lib2.a and lib3.a which have been compiled using ICC. I  used ICC with -ipo -c for compilation to create .o files and then XIAR for creating .a libraries. 

I want to give these three libraries to a customer who does not have ICC and hence will be using GCC to link his application with these libraries. Will the speed-gain (expected from -ipo built libraries) not be achieved at all if she links these libraries using GCC?

This page on "GCC* Compatibility and Interoperability" states:

"Link-time optimization using the -ffat-lto-objects compiler option is provided for gcc* compatibility. This implies that ld and ar can be used to link and archive object files, but by doing so you will lose cross-file optimizations."

Further, if case the speed-gains are supposed to get lost with linking with GCC, then if I change my setup some thing like this;

lib1.a lib2.a lib3.a and a wrapper source file wrapper.c

All the references made by my customer's application are exclusively present in wrapper.c. And then I executed this command:

xild -o plugin.a wrapper.o lib1.a lib2.a lib3.a -r -static

Now if any linking is taking place, then I expected the size of plugin.a to be considerably smaller then the combined size of [wrapper.o + lib1.a + lib2.a + lib3.a]. As I understand my libraries had extra files for Intermediate Representation (.ilo files) which take more memory than real object files. And if cross-file optimizations had happened, then such files would have been discarded after use. But the size of plugin.a remains the same as the sum of the size my libraries, implying the cross-file optimizations did not take place.

Is there any way to get the benefit of -ipo flag as much as possible without the customer having to use ICC for his application?

Any help will be appreciated. Apologies for such long query.

[KitturGanesh · Accepted solution]

Hi Govind,
In the case scenario you describe, the libraries will have regular object code similarly to effectively compiling with or close to -ip option and fake objects (made of IL). Nevertheless, these fake object files will not be of any uyse to those not using ICC and will be ignored by GCC. 
Basically, they are dead weight in the archive as GCC won't be able to read out the ICC IL format anyways.  That said, the suggestion would be to just compile the files with -ip and send those instead.
 

Hope the above helps? Let me know if you have any other questions or need any clarifications, thanks

_Kittur
 

[jimdempseyatthecove]

Govind,

Another thing to check is to see if there are any issues when the stripped library is then subsequently used by a user with ICC.

Jim Dempsey 

[govind_s_1]

Jim,

I have updated my previous comment with additional details to use the library. And no, I didn't face any issues while linking this library with both ICC and GCC while creating a final application subsequently.

[govind_s_1]

Hi Kittur,

Thanks for clarifying it. Based on your reply I have understood that GCC can not directly use the ICC's mock-object file info. But I feel I might have found a workaround to it for my specific need. Please verify if it is possible. Here is my setup:

Application project: Has to be built using GCC

Lib_interface project: Built using ICC.

Main_library: Built using ICC and with -ipo option. Hence the archive will be having two sets of files: real-objects (.o) and mock-objects (.ilo).

Now, for creating Lib_interface.a I have used partial linking (-r flag):

xild -r -static -o Lib_interface.a Lib_interface.o Lib_interface.o Main_library.a

Thus most of the internal-linking will be completed while creating the Lib_interface.a. The size of thus created Lib_interface.a is huge (10x compared to lib generated without IPO). Now I am striping (strip -R __ildata objcopy -R __ildata Lib_interface.o no_ildata_lib_interface.o) the __ildata section of the Lib_interface.a which brings it back to the normal size (as without IPO). Then I finally link this library with my Application successfully using these commands:

xiar rus no_ildata_lib_interface.a no_ildata_lib_interface.o
icc-o outfile app.o no_ildata_lib_interface.a

So far so good. Now here is my concern: What if the partial linking which I performed did linking for real-objects and mock-objects separately. and the section which is retained inside the library after stripping the __ildata section is the one which is generated without using IPO information at all. Please confirm.

Regards,

Govind

[KitturGanesh]

Hi Govind,
BTW, when you invoke "xild -r" to create a relocatable object that will have two parts, one containing the  IL  (fake/mock object code) in an
__ildata section that can be used in a further IPO type compilations; the other part of course will contain normal object code as well. 
Now, if you use "objcopy -R" to remove the __ildata section you've effectively destroyed the IPO aspect of the compilation. Anything you link to the resulting stripped object file will be to the code in the relocatable object that was compiled without IPO.   
Although your intention is to strip __ildata because it's large, it is precisely that which makes IPO work correctly. So, my suggestion would be: rather than stripping out the __ildata, you should just compile without IPO or keep the __ildata thereof.  Also, what you point out is correct in that teh section which is retained inside the library after stripping the __ildata section is the one which is generated without using IPO information at all. 
_Kittur

[KitturGanesh]

Hi Govind,
BTW, I did confirm with our IPO developer expert on the info I provided as correct, fyi.
_Kittur

[govind_s_1]

Hi Kittur,

Thank you very much for all the valuable information. This thread has become very helpful indeed.

Could you please confirm the same thing in the context of shared libraries? I will explain my setup once again:

application project: Has to be built using GCC

lib_interface project: Built using ICC. Should be a shared library(.so).

main_library: Built using ICC and with -ipo option. Is a static library(.a).

Now, when I am producing the libinterface.so using this command:

icc -shared -o libinterface.so wraper.o libmain.a

The libinterface.so is not showing any __ildata section with objdump utility (objdump --headers libinterface.so). With the static libraries earlier, I was able to see a separate such section. Is this behavior expected? If yes, then if I link this libinterface.so with the application using GCC, will I be able to achieve any IPO benefits?

My ultimate goal is to get IPO benefits with a client who does not have ICC compiler and I have realized that this is not possible with releasing her a static library. So I have moved on to explore to shared libraries. Further, I can not test the success of these (IPO) operations by running my executable because the machine I am testing on, gives quite fluctuating performance from run-to-run.

Govind

[govind_s_1]

Hi Kittur,

Thanks for sharing this valuable information. This thread has become very helpful indeed.

My ultimate goal is to ship a library (with IPO optimized performance) to a customer who does not have ICC installed. I have realized that this is not possible with a shared library. Could you please confirm if this is the same case with shared libraries?

I will explain my setup once again:

Application: GCC built.

Interface Library: ICC built.. Shared library (.so)

Main Library: Built using ICC with -ipo. Static library (.a).

Now when I generate the libinterface.so using this command:

icc -shared -o libinterface.so wrapper.o libmain.a

The generated libinterface.so does not show any __ildata section as the earlier static library used to show with objdump command (objdump --headers libinerface.a). Does this mean that while creating the libinterface.so the ICC compiler has discarded all the intermediate-language data present in the libmain.a? Or does it mean that ICC fully utilized the intermediate-language data while creating libinterface.so and it can now be used with GCC linker also (I am praying this to be true)?

I cannot verify this by running an example executable on my setup as I see a fluctuating performance on my machine among different runs.

Govind

[KitturGanesh]

Hi Govind,
     Yes, with that scenario ICC should have used the IL data in generating an optimized .so shared library!
_Kittur