LTO

Posted Aug 22, 2014 9:28 UTC (Fri) by epa (subscriber, #39769)
Parent article: Kernel tinification

Instead of (possibly buggy) link-time optimization, could you not concatenate all the source files into one enormous translation unit and compile that with optimization? If nothing else, it would be a great stress test for gcc. Perhaps even with today's large memory sizes (128 gigabytes, say) it is still not practical.

LTO

Posted Aug 22, 2014 10:54 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

I'm not overly familiar with the Linux kernel source, but it seems to me that individual translation units (source files) might use »static« declarations at top level to keep identifiers local to that translation unit, which is a popular programming technique in C.

Simply concatenating everything to make one huge translation unit would presumably fail if a name is declared that way in two different source files.

LTO

Posted Aug 29, 2014 21:07 UTC (Fri) by nix (subscriber, #2304) [Link]

Not only do they do that -- they even do things like #include files that declare structure types with the same name but different members depending on #defines that vary per translation unit.

There's no *way* you can handle that in the same TU.

LTO

Posted Aug 28, 2014 9:01 UTC (Thu) by yoshi314 (guest, #36190) [Link] (1 responses)

i wonder if -whole-program can be used in final link stage.

LTO

Posted Aug 29, 2014 10:37 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> i wonder if -whole-program can be used in final link stage.

Normally, no - because in the final link stage all you (normally) have are the already compiled and optimized object files. You need the source code in some form [also] available, and that's *exactly* what gcc's LTO does. There's not much more to it.

And, it's a lot less buggy than a few years ago.