Re: LTO and ABI compatibility
Hi Ian,
On 7/19/22 19:24, Ian Jackson wrote:
How does LTO work with ABI compatibility, which we rely on very
heavily ?
Symbols that are visible to the dynamic linker or that have their
address taken are hard borders for optimization, even in non-LTO builds.
For example,
int a() { return 1; }
int b() { return a(); }
will compile both functions to "mov eax, 1; ret" with -O2, but if you
also set -fPIC, b() becomes "xor eax, eax; jmp a@PLT" to allow a
LD_PRELOAD library to override a.
It is allowed to generate constant-propagation or inlined versions of
externally visible functions, but these may be called only if the symbol
has not been overridden, gcc knows to check for this, but the lookup is
expensive enough that it is only generated as a check before a loop.
Eg, my reading of the spec is as follows: if I add members
to an enum in a new library version, making a combined program
containing translation units with the old enum, and ones with the new
enum, is UB.[1]
If you add members in a way that does not cause existing definitions to
change, that is supposed to be ABI compatible. LTO builds may emit a
warning that the types are different because now there is a way to
detect this case.
Frannkly, I think enabling LTO by default is a mistake. The
performance benefits are not likely to be worth the bugs silently
introduced across our codebase. If there are particular programs that
would benefit from it, by all means enable it in those cases.
I agree that the performance isn't worth it, but I find the extended
diagnostics useful, I've found quite a few bugs this way, mostly
inconsistent duplicate declarations in different header files that were
never included together.
Simon
Reply to: