ipo vs ipo-c

[Yang__Richard]

So I've been under the impression that `ipo` and `ipo-c` ultimately produce identical results, barring the fact that ipo-c *should* produce 1 object file. 

I say *should* because I've had instances where it produces <i>more than</i> 1 object file; for instance, while compiling the Debian protobuf source package, I found ipo_out1.o, ipo_out2.o, and etc. (not a ton more, but perhaps a few more IIRC). Why?

BTW, as an aside, the Intel C++ Compiler produces HUGE resulting libraries for protobuf. At least one resulting static library was very close to 1GB, and the corresponding shared library I believe was around 600MB.

A quick `dpkg-query -Wf '${Installed-Size}\t${Package}\n'</span>` produces:
643184  libprotobuf-dev
940875  libprotoc-dev

But onto the real question--why doesn't ipo and ipo-c produce identical or even close to identical results? ipo-c seems to consistently produce smaller final products.

If I use ipo-c with numerous C sourcle files to produce a single ipo_out.o, and then use xiar crv libz.o, I get a smaller libz.a than with seperate -ipo -c compilations and a xiar crv libz.a [object files].

Does using ipo-c allow for a "better" (more optimized/faster) result than plain ipo? Are there other benefits to using ipo-c besides creating less intermediate objects?

[Viet_H_Intel]

ipo-c should generate a single object file. Not sure what happened in your case, but if you provide a reproducer, we can take a look.

Were there any differences at the link time for ipo and ipo-c, which could lead to a size difference in the binary?

ipo-c performs the same optimizations as ipo, but it stops before the final link stage, so that the object file can be used in the final linkage. So, I don't think there are other benefits.