[The World of Linkers—Theory 12] What Changes When the Optimizer Can See Across Files?

Separate compilation is both a build-system advantage and an information boundary. A declaration lets main.c call a function defined in util.c, but does not reveal its body. When the linker receives both objects, that body is usually machine code. Symbols and relocations can connect the call; they do not preserve the compiler’s original representation of its data flow and control flow. Cross-file inlining requires cooperation beyond connecting references.

Link-time optimization, LTO¹, moves this boundary. Compilation retains an intermediate representation, IR, that the optimizer can still analyze. The linker selects definitions and determines their external visibility. The compiler then optimizes and generates machine code under those constraints. Source organization remains modular while analysis can cross module boundaries.

LTO, GC, and ICF can all reduce emitted code, but use different criteria: LTO transforms the program representation, GC removes unreachable sections, and ICF lets equivalent sections share storage. Definition selection and section references, introduced in Theory 03 and Theory 05, provide the prerequisites. A cross-file call exposes the division of responsibility; ThinLTO, folding correctness, and code locality build on it.

The call that disappears

The caller repeatedly invokes scale; the second file also defines two functions that this program never uses:

1
// main.c
2
int scale(int x);
3

4
int main(int argc, char **argv) {
5
    unsigned s = 0;
6
    for (int i = 0; i < 400000000; i++)
7
        s += scale(i ^ argc);
8
    return s >> 24;
9
}

1
// util.c
2
int scale(int x) { return 3 * x + 1; }
3

4
int twice(int x) { return 2 * x; }
5

6
unsigned checksum(const unsigned char *p, int n) {
7
    unsigned h = 2166136261u;
8
    for (int i = 0; i < n; i++)
9
        h = (h ^ p[i]) * 16777619u;
10
    return h;
11
}

With ordinary separate -O2 compilation, the caller retains a call because it cannot see the body. The callee's translation unit must retain its global definitions because another file might need them. With full LTO, both bodies become available to one optimization task.

These experiments run natively on x86-64 Linux, using Ubuntu 26.04, Clang/LLD 21.1.8, GCC² 15.2, and GNU³ binutils⁴ 2.46. Here link_musl denotes a configured shell helper whose contract is to pass its inputs to the host Linux musl⁵ startup objects, libc, and ld.lld. The installation paths are system configuration details; the argument and output contract is what matters for the analysis. This is native linking against an alternative Linux C library.

1
$ # set the variables required by the commands below
2
$ mkdir -p "$W/puzzle"
3
$ # copy the two source files into the temporary puzzle directory
4
$ cd "$W/puzzle"
5
$ clang -fno-pie -O2 -c main.c -o main.o
6
$ clang -fno-pie -O2 -c util.c -o util.o
7
$ link_musl plain main.o util.o
8
$ clang -fno-pie -O2 -flto -c main.c -o main.lto.o
9
$ clang -fno-pie -O2 -flto -c util.c -o util.lto.o
10
$ link_musl lto main.lto.o util.lto.o
11
$ llvm-nm -S plain | grep -E ' (main|scale|twice|checksum)$'
12
0000000000201330 0000000000000095 T checksum
13
00000000002012d0 0000000000000032 T main
14
0000000000201310 0000000000000006 T scale
15
0000000000201320 0000000000000004 T twice
16
$ llvm-nm -S lto | grep -E ' (main|scale|twice|checksum)$'
17
0000000000201a30 00000000000000a0 T main
18
$ llvm-size plain lto
19
   text	   data	    bss	    dec	    hex	filename
20
   2408	     40	   1768	   4216	   1078	plain
21
   2282	     40	   1896	   4218	   107a	lto

Only main survives among the four named functions. scale is inlined; the other two definitions have no remaining user. Meanwhile main grows from 0x32 to 0xa0 bytes. Removing the call lets the compiler vectorize the loop:

1
$ llvm-objdump -d --no-show-raw-insn --disassemble-symbols=main plain
2
00000000002012d0 <main>:
3
  ...
4
  2012e0:      	movl	%r14d, %edi
5
  2012e3:      	xorl	%ebp, %edi
6
  2012e5:      	callq	0x201310 <scale>
7
  2012ea:      	addl	%eax, %ebx
8
  ...
9
$ llvm-objdump -d --no-show-raw-insn --disassemble-symbols=main lto
10
0000000000201a30 <main>:
11
  201a30:      	movd	%edi, %xmm0
12
  201a34:      	pshufd	$0x0, %xmm0, %xmm1      # xmm1 = xmm0[0,0,0,0]
13
  ...
14
  201a70:      	movdqa	%xmm2, %xmm7
15
  201a74:      	paddd	%xmm3, %xmm7
16
  ...
17
  201aad:      	addl	$-0x8, %eax
18
  201ab0:      	jne	0x201a70 <main+0x40>

The SSE instructions operate on multiple integer lanes at once. The llvm-size text category falls by 126 bytes, but that category includes more than .text, and BSS grows from 1,768 to 1,896 bytes. A smaller text column does not establish smaller total memory use.

Both executables return 110. The recorded Clang timings were 0.83 and 0.77 seconds without LTO, versus 0.09 and 0.06 seconds with it. GCC's three pairs were 0.722/0.897/0.968 versus 0.321/0.309/0.312 seconds. These demonstrate this loop's changed generated code, not a universal LTO speedup. GCC's size comparison is:

1
   text    data    bss    dec    hex filename
2
   1494     544      8   2046    7fe a_plain
3
   1265     544      8   1817    719 a_lto

An object filename does not promise machine code

Clang's⁶ -flto -c output still ends in .o, but this configuration writes LLVM bitcode:

1
$ file main.o main.lto.o
2
main.o:     ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
3
main.lto.o: LLVM IR bitcode
4
$ xxd main.lto.o | head -1
5
00000000: 4243 c0de 3514 0000 0500 0000 620c 3024  BC..5.......b.0$
6
$ readelf -h main.lto.o
7
readelf: Error: This is a LLVM bitcode file - try using llvm-bcanalyzer
8
$ stat -c '%n: %s bytes' main.o main.lto.o
9
main.lto.o: 2768 bytes
10
main.o: 1144 bytes

LLVM⁷ IR⁸ represents control flow and data flow before final instruction selection. Bitcode is its binary encoding, identified here by BC followed by 0xc0de. Disassembling the IR shows multiplication and addition rather than x86 instructions:

1
$ llvm-dis util.lto.o -o - | grep -A4 '@scale'
2
define dso_local range(i32 -2147483647, -2147483648) i32 @scale(i32 noundef %0) local_unnamed_addr #0 {
3
  %2 = mul nsw i32 %0, 3
4
  %3 = add nsw i32 %2, 1
5
  ret i32 %3
6
}

Some optimization has already happened during compilation. Full LTO subsequently combines the participating modules, making cross-file inlining an ordinary optimization within that combined representation.

The linker need not understand the whole IR to resolve its symbols:

1
$ llvm-bcanalyzer -dump main.lto.o | grep -oE '^ *<[A-Z_]+BLOCK' | sort | uniq -c
2
...
3
   1   <FULL_LTO_GLOBALVAL_SUMMARY_BLOCK
4
   1   <FUNCTION_BLOCK
5
   ...
6
   1 <IDENTIFICATION_BLOCK
7
   1 <MODULE_BLOCK
8
   1 <STRTAB_BLOCK
9
   1 <SYMTAB_BLOCK
10
$ llvm-bcanalyzer -dump util.lto.o | grep -A1 -m1 IDENTIFICATION_BLOCK
11
<IDENTIFICATION_BLOCK_ID NumWords=5 BlockCodeSize=5>
12
  <STRING abbrevid=4 op0=76 op1=76 op2=86 ... /> record string = 'LLVM21.1.8'
13
$ llvm-nm main.lto.o util.lto.o
14
main.lto.o:
15
---------------- T main
16
                 U scale
17

18
util.lto.o:
19
---------------- T checksum
20
---------------- T scale
21
---------------- T twice

A precomputed SYMTAB_BLOCK supplies names and attributes. The dashed address field in llvm-nm is appropriate: no final machine-code address exists yet.

GCC's slim and fat objects

GCC preserves GIMPLE in .gnu.lto_* sections inside an ELF⁹ object:

1
$ gcc -O2 -flto -c util.c -o util.slim.o
2
$ gcc -O2 -flto -c main.c -o main.slim.o
3
$ gcc -O2 -flto -ffat-lto-objects -c util.c -o util.fat.o
4
$ gcc -O2 -c util.c -o util.gcc.o
5
$ stat -c '%n: %s bytes' util.fat.o util.gcc.o util.slim.o
6
util.fat.o: 5664 bytes
7
util.gcc.o: 1440 bytes
8
util.slim.o: 5168 bytes
9
$ readelf -SW util.slim.o
10
(excerpt)
11
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
12
  [ 1] .text             PROGBITS        0000000000000000 000040 000000 00  AX  0   0  1
13
  [ 7] .gnu.lto_.inline.ce6e4b4d6bbe9a11 PROGBITS        0000000000000000 0000a3 000063 00   E  0   0  1
14
  [12] .gnu.lto_scale.0.ce6e4b4d6bbe9a11 PROGBITS        0000000000000000 000199 0000fb 00   E  0   0  1
15
  [13] .gnu.lto_twice.1.ce6e4b4d6bbe9a11 PROGBITS        0000000000000000 000294 0000ea 00   E  0   0  1
16
  [14] .gnu.lto_checksum.2.ce6e4b4d6bbe9a11 PROGBITS        0000000000000000 00037e 000230 00   E  0   0  1
17
  [18] .gnu.lto_.symtab.ce6e4b4d6bbe9a11 PROGBITS        0000000000000000 000905 000042 00   E  0   0  1
18
$ readelf -sW util.slim.o | tail -1
19
2: 0000000000000001     1 OBJECT  GLOBAL DEFAULT  COM __gnu_lto_slim
20
$ readelf -SW util.fat.o | grep ' .text'
21
[ 1] .text             PROGBITS        0000000000000000 000040 00005e 00  AX  0   0 32

The sections contain per-function representations, summaries, symbols, and options. Their SHF_EXCLUDE flag prevents them from becoming ordinary output payload. Generated suffixes can vary between compilations; supplying -frandom-seed=x made repeated objects byte-identical in this test.

A slim object has no useful machine-code implementation in .text; its ordinary ELF symbols include a marker such as __gnu_lto_slim, not the full function inventory. A fat object adds machine code alongside GIMPLE, allowing a non-LTO linker to use the native half. That costs additional bytes and compilation work, without implying an exact doubling.

GNU nm¹⁰ appears to read slim symbols because an installed plugin teaches it how:

1
$ nm util.slim.o
2
00000000 T checksum
3
00000000 T scale
4
00000000 T twice
5
$ nm --plugin /dev/null util.slim.o
6
nm: util.slim.o: plugin needed to handle lto object
7
0000000000000001 C __gnu_lto_slim

Without that plugin, the ordinary symbol table cannot reveal what lives only in GIMPLE. Tool capability depends on the installed reader, not merely its command name.

The resolution contract

Separate three roles. The compiler frontend turns source into IR; the linker chooses global definitions and identifies references that must survive; the compiler's LTO backend optimizes IR under those constraints and generates machine code. IR retains function bodies and relationships between operations. Bitcode is LLVM's file encoding of that representation, not a machine-code section awaiting address patches.

An ordinary link receives machine-code functions and connects them through symbols and relocations. This LTO input still describes scale's calculation, so the backend can move it into main's loop and remove an independent definition with no outside users. Removing it requires global-resolution evidence: the absence of callers in the current IR alone does not establish that a public interface is unused.

A selected definition does not yet have a final address. Optimization may change sizes or introduce references; placement follows later. The resolution file below shows the first stage, intermediate bitcode shows the second, and the link map shows the third. These observation points distinguish choosing a definition from rewriting a function. LLVM's LTO design describes this cooperation.

The linker first resolves symbols across IR, ordinary objects, and lazily extracted archive members. Strong and weak definitions, COMDAT¹¹ selection, and archive demand still matter. It then reports those decisions to the optimizer:

1
$ link_musl lto main.lto.o util.lto.o --save-temps
2
$ cat lto.resolution.txt
3
main.lto.o
4
-r=main.lto.o,main,plx
5
-r=main.lto.o,scale,l
6
util.lto.o
7
-r=util.lto.o,scale,pl
8
-r=util.lto.o,twice,pl
9
-r=util.lto.o,checksum,pl

The resolution flags distinguish three questions:

main has x because ordinary startup code references it. The definition of scale has pl but no x: only IR uses it. LTO can internalize it, then optimize or remove it as an internal entity.

Saved intermediate files separate the stages:

1
$ ls
2
lto  lto.0.0.preopt.bc  lto.0.2.internalize.bc  lto.0.4.opt.bc  lto.0.5.precodegen.bc
3
lto.lto.o  lto.resolution.txt  main.lto.o  util.lto.o
4
$ llvm-dis lto.0.0.preopt.bc -o - | grep -E '^define'
5
define dso_local range(i32 0, 256) i32 @main(i32 noundef %0, ptr noundef readnone captures(none) %1) local_unnamed_addr #0 {
6
define dso_local range(i32 -2147483647, -2147483648) i32 @scale(i32 noundef %0) local_unnamed_addr #1 {
7
$ llvm-dis lto.0.2.internalize.bc -o - | grep -E '^define'
8
define dso_local range(i32 0, 256) i32 @main(i32 noundef %0, ptr noundef readnone captures(none) %1) #0 {
9
define internal range(i32 -2147483647, -2147483648) i32 @scale(i32 noundef %0) #1 {
10
$ llvm-dis lto.0.4.opt.bc -o - | grep -E '^define'
11
define dso_local range(i32 0, 256) i32 @main(i32 noundef %0, ptr noundef readnone captures(none) %1) local_unnamed_addr #0 {
12
$ file lto.lto.o
13
lto.lto.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

For this IR excerpt, track the function name after define and the internal marker. define introduces a function body; internal limits its name to this IR module. Parameter attributes and range hints are not needed to determine which functions survive here.

The unneeded twice and checksum never reach the combined live module. Internalization changes scale's linkage while leaving its body present; it does not itself mean deletion. Optimization then inlines and removes the out-of-line body. Finally lto.lto.o is an ordinary relocatable ELF object, still awaiting conventional layout and relocation.

The linker must consume that generated object and process its definitions and references. Code generation can introduce new runtime-library references, so the earlier resolution pass is not a promise that no more symbol work will occur. In this fixture, generated code is added after the original inputs, which also explains why main moves later in the layout.

A plugin or a compiler library inside the linker

LLD calls LLVM's LTO libraries directly. GNU ld and gold can load a compiler-supplied plugin. The essential handshake is: initialize callbacks, let the plugin claim IR inputs, report their symbols, return resolutions after reading inputs, run the compiler backend, and add the generated native objects back to the link.

GCC's verbose driver output exposes that chain:

1
$ gcc -O2 -flto -static main.slim.o util.slim.o -o g_lto -v
2
...
3
collect2 -plugin /usr/libexec/gcc/x86_64-linux-gnu/15/liblto_plugin.so
4
  -plugin-opt=/usr/libexec/gcc/x86_64-linux-gnu/15/lto-wrapper
5
  -plugin-opt=-fresolution=$TMPDIR/cc-resolution.res
6
  -plugin-opt=-pass-through=-lgcc
7
  ...
8
$ file /usr/libexec/gcc/x86_64-linux-gnu/15/liblto_plugin.so
9
...liblto_plugin.so: ELF 64-bit LSB shared object, x86-64
10
$ nm g_lto | grep -E ' (main|scale|twice|checksum)$'
11
00000000004016e0 T main

collect2¹² wraps the linker; liblto_plugin.so participates in the linker process; lto-wrapper invokes GCC's LTO compiler, lto1. The plugin itself is a host shared library, because the host linker must load it. GCC's saved resolution file expresses the same boundary using different names:

1
$ gcc -O2 -flto -static -save-temps main.slim.o util.slim.o -o g
2
$ cat g.res
3
2
4
main.slim.o 2
5
204 6e2bab631856fa31 PREVAILING_DEF main
6
208 6e2bab631856fa31 RESOLVED_IR scale
7
util.slim.o 3
8
202 20956cafc9f8deba PREVAILING_DEF_IRONLY scale
9
204 20956cafc9f8deba PREVAILING_DEF_IRONLY twice
10
209 20956cafc9f8deba PREVAILING_DEF_IRONLY checksum

PREVAILING_DEF_IRONLY corresponds to a chosen definition visible only within IR. main lacks IRONLY because startup code needs it. The same compiler plugin can work with different supporting linkers. Independently, BFD plugins can help tools such as ar¹³ and nm inspect IR.

When a symbol unexpectedly disappears, read the resolution record before blaming an optimization pass. If the linker said “IR only,” deletion may be exactly what it authorized.

Debug information is generated after the transformation

With -g, bitcode carries metadata such as DICompileUnit and DISubprogram; it does not yet contain final .debug_* sections:

1
$ clang -fno-pie -O2 -g -flto -c main.c -o main.o
2
$ clang -fno-pie -O2 -g -flto -c util.c -o util.o
3
$ llvm-dis main.o -o - | grep -E '^!.* = distinct !DICompileUnit|^!.* = distinct !DISubprogram'
4
!0 = distinct !DICompileUnit(language: DW_LANG_C11, file: !1, producer: "Ubuntu clang version 21.1.8 (6ubuntu1)", isOptimized: true, ...)
5
!9 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 4, ...)
6
$ link_musl prog main.o util.o --save-temps
7
$ llvm-readelf -SW prog.lto.o | grep -E '\.debug_'
8
[ 6] .debug_abbrev     PROGBITS        0000000000000000 000110 0000cd 00      0   0  1
9
  [ 7] .debug_info       PROGBITS        0000000000000000 0001dd 0000b4 00      0   0  1
10
  [ 8] .rela.debug_info  RELA            0000000000000000 0006a0 000120 18   I 22   7  8
11
  [ 9] .debug_str_offsets PROGBITS       0000000000000000 000291 000040 00      0   0  1
12
  [10] .rela.debug_str_offsets RELA      0000000000000000 0007c0 000150 18   I 22   9  8
13
  [11] .debug_str        PROGBITS        0000000000000000 0002d1 000084 01  MS  0   0  1
14
  [12] .debug_addr       PROGBITS        0000000000000000 000355 000020 00      0   0  1
15
  [13] .rela.debug_addr  RELA            0000000000000000 000910 000048 18   I 22  12  8
16
  [18] .debug_line       PROGBITS        0000000000000000 0003f8 0000dd 00      0   0  1
17
  [19] .rela.debug_line  RELA            0000000000000000 000970 000090 18   I 22  18  8
18
  [20] .debug_line_str   PROGBITS        0000000000000000 0004d5 00002c 01  MS  0   0  1
19
$ llvm-dwarfdump --debug-info prog.lto.o | grep -E 'DW_TAG_(compile_unit|subprogram|inlined_subroutine)|DW_AT_abstract_origin|DW_AT_name\t\("(main|util)\.c"\)|DW_AT_name\t\("(main|scale)"\)'
20
0x0000000c: DW_TAG_compile_unit
21
              DW_AT_name	("main.c")
22
0x00000023:   DW_TAG_subprogram
23
                DW_AT_name	("main")
24
0x0000005e:       DW_TAG_inlined_subroutine
25
                    DW_AT_abstract_origin	(0x000000000000009e "scale")
26
0x0000008c: DW_TAG_compile_unit
27
              DW_AT_name	("util.c")
28
0x0000009e:   DW_TAG_subprogram
29
                DW_AT_name	("scale")

The backend emits DWARF¹⁴ for the resulting code. The inlined scale appears beneath main as DW_TAG_inlined_subroutine, referring to an abstract origin in the other CU. The debug record describes an actual cross-file transformation, rather than pretending the original call survived.

Visibility is an optimization boundary

Dynamic exports

A runtime plugin can name a function that no current IR call mentions. The linker must communicate that possibility. Consider:

1
// app.c
2
int plugin_hook(int x) { return x + 100; }   // not called by this program
3
int helper(int x) { return x * 2; }
4

5
int main(void) { return helper(21); }

1
$ clang -fno-pie -O2 -flto -c app.c -o app.o
2
$ link_musl_dyn app_dyn app.o
3
$ llvm-nm app_dyn | grep -E ' (main|helper|plugin_hook)$'
4
00000000000013d0 T main
5
$ link_musl_dyn app_ed app.o --export-dynamic --save-temps
6
$ cat app_ed.resolution.txt
7
app.o
8
-r=app.o,plugin_hook,plx
9
-r=app.o,helper,plx
10
-r=app.o,main,plx
11
$ llvm-nm -D --defined-only app_ed
12
0000000000001509 T _fini
13
0000000000001506 T _init
14
0000000000001490 T _start
15
00000000000014b0 T _start_c
16
00000000000014f0 T helper
17
0000000000001500 T main
18
00000000000014e0 T plugin_hook

link_musl_dyn builds a dynamically linked musl PIE¹⁵. Without export options, plugin_hook disappears and helper disappears after inlining. With --export-dynamic, eligible default-visible globals become dynamically visible and acquire x. The compiler may still inline a known call to helper, but must retain its callable exported definition.

A shared library normally exports its default-visible globals. A version script can reduce that public set:

1
$ cat lib.map
2
{ global: api_get; local: *; };
3
$ clang -fno-pie -O2 -fPIC -flto -c lib.c -o lib.o
4
$ ld.lld -shared lib.o -o lib_all.so
5
$ llvm-nm -D --defined-only lib_all.so
6
00000000000012c0 T api_get
7
00000000000012d0 T impl_detail
8
$ ld.lld -shared --version-script=lib.map lib.o -o lib_map.so
9
$ llvm-nm -D --defined-only lib_map.so
10
0000000000001280 T api_get
11
$ llvm-nm lib_map.so | grep -E 'api_get|impl_detail'
12
0000000000001280 T api_get

Without LTO, making impl_detail local can remove its dynamic export while leaving machine code. With LTO, that information arrives early enough to internalize and eliminate an unused definition. Hidden visibility offers a related constraint already visible during compilation.

A reference hidden inside assembly text

Function-local inline assembly is not generally parsed as an IR-level symbol dependency:

1
// asm_main.c: helper2 is referenced only inside inline assembly
2
int main(void) {
3
    int r;
4
    __asm__ volatile("call helper2" : "=a"(r) : : "rdi", "rsi", "rdx", "rcx", "r8", "r9", "r10", "r11", "memory");
5
    return r;
6
}

1
// asm_util.c
2
int helper2(void) { return 7; }

1
$ link_musl asm_plain asm_main.o asm_util.o            # without LTO
2
$ link_musl asm_lto asm_main.lto.o asm_util.lto.o --save-temps
3
ld.lld: error: undefined symbol: helper2
4
>>> referenced by ld-temp.o
5
>>>               asm_lto.lto.o:(main)
6
$ cat asm_lto.resolution.txt
7
asm_main.lto.o
8
-r=asm_main.lto.o,main,plx
9
asm_util.lto.o
10
-r=asm_util.lto.o,helper2,pl

Ordinary assembly creates an undefined reference to helper2, so the normal link sees it. During LTO, the opaque assembly string did not tell the resolver that the helper was needed. Its definition was removed before the backend's assembler finally discovered the call. A diagnostic naming ld-temp.o points into that generated stage.

This fixture isolates symbol visibility. Hiding a real function call inside inline assembly also requires correct stack alignment, register clobbers, and red-zone handling. Retaining the callee does not repair an incomplete calling-convention description. Prefer a normal C call or an independently assembled function with an explicit interface.

File-scope module assembly is handled differently: the bitcode symbol-table builder can parse it for definitions and references:

1
// toplevel.c: define a function in module-level assembly
2
__asm__(".text\n.globl asm_seven\n.type asm_seven,@function\nasm_seven:\n  movl $7, %eax\n  ret\n");

1
$ llvm-nm toplevel.lto.o
2
---------------- T asm_seven
3
$ link_musl top top_main.lto.o toplevel.lto.o && llvm-nm top | grep -E ' (main|asm_seven)$'
4
00000000002019ec T asm_seven
5
0000000000201a00 T main

For the visibility experiment, used explicitly preserves the otherwise invisible helper:

1
// asm_util_used.c
2
__attribute__((used)) int helper2(void) { return 7; }

1
$ link_musl asm_used asm_main.lto.o asm_util_used.lto.o && llvm-nm asm_used | grep -E ' (main|helper2)$'
2
0000000000201a00 T helper2
3
00000000002019f0 T main

LLVM records it in llvm.used, protecting it from internalization/removal in this path. That does not make it a linker-GC root. Section GC¹⁶ is another layer; an ELF retain attribute or script KEEP addresses that layer.

Archives have more than one reader

An archive indexer must identify symbols, and the final link must also generate code from the IR. Those are separate capabilities:

1
ar rcs libm3_gnu.a mul3.o other.o
2
llvm-ar rcs libm3_llvm.a mul3.o other.o
3
nm -s libm3_gnu.a
4
llvm-nm --print-armap libm3_llvm.a

On this machine, both GNU ar and llvm-ar create useful LLVM-bitcode indexes because the LLVM BFD plugin is installed. LLD links either archive and extracts the needed mul3 member. The unneeded other member does not become a definition source. The default GCC static-link path nevertheless rejects these LLVM inputs: successful indexing did not configure a matching LLVM LTO backend.

GCC slim objects demonstrate the inverse mismatch:

1
$ ar rcs libm3_slim.a mul3.gcc.o other.gcc.o
2
$ nm -s libm3_slim.a
3
Archive index:
4
mul3 in mul3.gcc.o
5
other in other.gcc.o
6
$ readelf -sW mul3.gcc.o | tail -1
7
     2: 0000000000000001     1 OBJECT GLOBAL DEFAULT COM __gnu_lto_slim

GNU ar can index their GIMPLE symbols. LLD does not run GCC's optimizer, so reading their ordinary ELF view does not produce a definition of mul3. Use a matching GCC LTO driver, or publish fat objects with machine code for fallback linking. The fallback retains mul3 as an ordinary function; the matching LTO build can inline it. All successful variants in the recorded two-argument test returned 9.

ThinLTO: global decisions, separate backends

Full LTO's combined optimization can become a large, repeatedly rebuilt task. This does not mean every full-LTO implementation is single-threaded: implementations can partition work or parallelize code generation. ThinLTO takes a specific alternative approach based on summaries.

Each module records function size, calls, references, and other analysis facts:

1
$ clang -fno-pie -O2 -flto=thin -c main.c -o main.thin.o
2
$ clang -fno-pie -O2 -flto=thin -c util.c -o util.thin.o
3
$ llvm-bcanalyzer -dump main.thin.o | sed -n '/<GLOBALVAL_SUMMARY_BLOCK/,/<\/GLOBALVAL_SUMMARY_BLOCK/p'
4
  <GLOBALVAL_SUMMARY_BLOCK NumWords=22 BlockCodeSize=4>
5
    <VERSION op0=12/>
6
    <FLAGS op0=0/>
7
    <PERMODULE_PROFILE abbrevid=5 op0=0 op1=64 op2=11 op3=64 op4=0 op5=0 op6=0 op7=1 op8=8/>
8
  </GLOBALVAL_SUMMARY_BLOCK>

A thin-link phase resolves symbols and combines those summaries into a global index. It determines liveness, internalization, and which function bodies each backend should import:

1
$ link_musl thin main.thin.o util.thin.o --save-temps
2
$ cat thin.index.dot
3
  ...
4
    M0_15822663052811949562 [shape="record",label="main|extern (inst: 11, ffl: 0000001000)}"]; // function, dsoLocal, definition, preserved
5
  ...
6
    M1_2563497542905672716 [shape="record",label="scale|extern (inst: 3, ffl: 1010001000)}"]; // function, dsoLocal, definition
7
    M1_12741001430464225570 [shape="record",label="checksum|extern (inst: 16, ffl: 0110001000)}",fillcolor="red"]; // function, dsoLocal, definition, dead
8
    M1_13517681653245979564 [shape="record",label="twice|extern (inst: 2, ffl: 1010001000)}",fillcolor="red"]; // function, dsoLocal, definition, dead
9
  ...
10
  // Cross-module edges:
11
  M0_15822663052811949562 -> M1_2563497542905672716 // call (hotness : Unknown)

Here main is preserved, scale is small enough to import, and the two unused functions are dead. The long identifiers are hashes used to name global values in the index.

Independent backends then optimize and generate each module. Imported bodies have available_externally linkage: available for analysis/inlining, without becoming an extra emitted definition in that importing module.

1
$ llvm-dis main.thin.o.3.import.bc -o - | grep -E '^define'
2
define dso_local range(i32 0, 256) i32 @main(...) local_unnamed_addr #0 {
3
define available_externally dso_local range(i32 -2147483647, -2147483648) i32 @scale(...) local_unnamed_addr #1 {
4
$ llvm-dis util.thin.o.2.internalize.bc -o - | grep -E '^define'
5
define dso_local range(i32 -2147483647, -2147483648) i32 @scale(...) local_unnamed_addr #0 {
6
$ llvm-nm thin | grep -E ' (main|scale|twice|checksum)$'
7
0000000000201a30 T main
8
0000000000201ad0 T scale

Unlike full LTO, this output still has an out-of-line scale. Its home backend cannot assume the separate importing backend will inline every call. Global summary decisions do not give each backend perfect knowledge of every other backend's final choices.

Independent tasks can be cached. The key accounts for the module, imported bodies, resolutions, and relevant options. LLD enables storage with --thinlto-cache-dir; cache policy controls eviction. See the ThinLTO documentation and the CGO 2017 paper.

Parallelism and caching remove different costs

LTO moves optimization and machine-code generation into the link phase. Its reported link time therefore includes compiler backend work as well as layout, relocation, and output writing. An ordinary link includes only the latter work. Comparing link times alone does not establish the cost of the complete build.

ThinLTO obtains parallelism from independent module backends. Summary analysis first determines imports and global constraints; the backends can then optimize and generate code concurrently. Their objects still require a conventional link. More workers primarily shorten the backend phase: they do not remove summary analysis or final linking, and a slow module still takes time to finish. With one worker, the cost of running a backend for each module remains, so ThinLTO need not beat full LTO.

Caching avoids repeating backend work. Reuse requires the module’s IR, imported content, resolutions, and relevant options to match the cache key. Changing one function can also affect modules that import it. The benefit follows those dependencies rather than merely the list of source files edited. The ThinLTO documentation describes parallel backends and incremental caching as distinct mechanisms.

Lua 5.4.7 supplies a concrete comparison: 33 C files excluding luac.c, roughly 24,000 lines, built with Clang/LLD 21.1.8 and musl. Each mode has five link-only samples, in seconds:

The median is 8.0087 seconds for serial ThinLTO, 4.1268 seconds with default parallelism, and 5.4255 seconds for full LTO. These samples illustrate reduced waiting through concurrent backends; they do not establish a fixed ranking across workloads.

The cache run took 4.2566 seconds initially, then 0.0743 and 0.0651 on unchanged repeats. After modifying and recompiling one implementation detail in lcorolib.c, linking took 0.2210 seconds. Cache entries rose from 34 to 35 because the old entry remained while other modules were reused.

1
   text    data    bss     dec    hex filename
2
 350224    1152   5360  356736  57180 lua-none
3
 412705    1160   4280  418145  66161 lua-full
4
 436170    1160   5432  442762  6c18a lua-thin

Full and ThinLTO text sizes increased by about 18% and 25%. All three programs ran the same Lua loop and printed Lua 5.4 89999997. A separate maximum-RSS measurement gave 67,152 KiB without LTO, 112,648 with full LTO, and 91,972/98,140/97,996 for ThinLTO with one/two/default backend concurrency. Those memory measurements came from another run; they are not additional columns from the timing samples above.

Identical code folding is a different optimization

ICF¹⁷ can merge differently named functions whose input sections are equivalent. COMDAT selects among definitions sharing an identity; ICF discovers equal implementations across identities. For ELF it works at input-section granularity, so -ffunction-sections makes individual functions eligible.

1
// icf.c
2
int add_i(int a, int b) { return a + b; }
3
int add_j(int a, int b) { return a + b; }
4
int (*pick(void))(int, int) { return add_j; }

1
$ clang -fno-pie -O2 -ffunction-sections -c icf.c -o icf.o
2
$ llvm-objdump -d icf.o
3
icf.o:	file format elf64-x86-64
4

5
Disassembly of section .text.add_i:
6

7
0000000000000000 <add_i>:
8
       0: 8d 04 37                     	leal	(%rdi,%rsi), %eax
9
       3: c3                           	retq
10

11
Disassembly of section .text.add_j:
12

13
0000000000000000 <add_j>:
14
       0: 8d 04 37                     	leal	(%rdi,%rsi), %eax
15
       3: c3                           	retq
16

17
Disassembly of section .text.pick:
18

19
0000000000000000 <pick>:
20
       0: b8 00 00 00 00               	movl	$0x0, %eax
21
       5: c3                           	retq
22
$ ld.lld -e pick --icf=all --print-icf-sections icf.o -o icf_all
23
selected section icf.o:(.text.add_i)
24
  removing identical section icf.o:(.text.add_j)
25
$ nm icf_all | grep -E 'add_|pick'
26
0000000000201170 T add_i
27
0000000000201170 T add_j
28
0000000000201180 T pick

The two add functions now have the same address. This first output uses -e pick for structural inspection without libc; it is not the runnable pointer-comparison test below.

Equal bytes can still call different functions

Relocation placeholders can be identical while their targets differ:

1
// chain.c: equal bytes, different call targets
2
int g1(int x) { return x * 5 + 1; }
3
int g2(int x) { return x * 5 + 1; }    // same as g1
4
int g3(int x) { return x * 7 + 1; }    // different from g1
5
int f1(int x) { return g1(x) + 2; }
6
int f2(int x) { return g2(x) + 2; }
7
int f3(int x) { return g3(x) + 2; }
8
int main(int argc, char **argv) { return f1(argc) + f2(argc) + f3(argc); }

1
$ clang -fno-pie -O2 -ffunction-sections -fno-inline -c chain.c -o chain.o
2
$ llvm-readelf -r chain.o | grep -E 'Relocation section|g[123]'
3
Relocation section '.rela.text.f1' at offset 0x340 contains 1 entries:
4
0000000000000002  0000000900000004 R_X86_64_PLT32         0000000000000000 g1 - 4
5
Relocation section '.rela.text.f2' at offset 0x358 contains 1 entries:
6
0000000000000002  0000000a00000004 R_X86_64_PLT32         0000000000000000 g2 - 4
7
Relocation section '.rela.text.f3' at offset 0x370 contains 1 entries:
8
0000000000000002  0000000b00000004 R_X86_64_PLT32         0000000000000000 g3 - 4
9
Relocation section '.rela.text.main' at offset 0x388 contains 3 entries:
10
Relocation section '.rela.eh_frame' at offset 0x3d0 contains 7 entries:
11
0000000000000020  0000000200000002 R_X86_64_PC32          0000000000000000 .text.g1 + 0
12
0000000000000034  0000000300000002 R_X86_64_PC32          0000000000000000 .text.g2 + 0
13
0000000000000048  0000000400000002 R_X86_64_PC32          0000000000000000 .text.g3 + 0
14
$ link_musl chain chain.o --icf=all --print-icf-sections 2>&1 | grep -A1 'chain.o:(.text.[fg]'
15
selected section chain.o:(.text.f1)
16
  removing identical section chain.o:(.text.f2)
17
selected section chain.o:(.text.g1)
18
  removing identical section chain.o:(.text.g2)
19
$ llvm-nm chain | grep -E ' [fg][123]$' | sort
20
00000000002012d0 T g1
21
00000000002012d0 T g2
22
00000000002012e0 T g3
23
00000000002012f0 T f1
24
00000000002012f0 T f2
25
0000000000201300 T f3

g1 and g2 are equivalent, so the matching callers f1 and f2 can merge. g3 differs, so f3 cannot join them. The runnable result stays 26.

Why refinement needs repetition

Requiring equal target section IDs would miss f1 and f2: they refer to distinct sections g1 and g2 that can share one contribution. Comparing only caller bytes would instead admit f3 incorrectly. What matters is the target's equivalence class.

An equivalence class groups sections that have not yet been shown incompatible. First group by contents and the fixed parts of relocations, then split groups according to their targets' classes. Groups only split; refinement stops when a pass makes no further split. Hashes can locate candidates efficiently, but equal hashes still require exact comparison.

Add another call level to see why one pass can be insufficient. Six sections form two chains: f1 → g1 → h1 and f2 → g2 → h2. The four callers have identical bytes and one relocation each, with equal field offsets, types, addends, and target-section offsets. The two leaves have different bytes. All six have passed eligibility checks. If each pass reads the previous partition, refinement proceeds as follows:

An implementation may use newly discovered splits earlier within a pass, changing the pass count while preserving the final relation. Termination follows because finitely many sections can split into only finitely many nonempty groups. Cycles do not require recursively reaching a leaf first: equally shaped mutually referring sections can remain in one class if every reference continues to target that class. The algorithm finds the largest relation satisfying these constraints; it does not prove arbitrary programs equivalent for every input.

LLD 21.1.8's implementation uses optimistic refinement and target-hash propagation to reduce exact comparison work. Eligibility and equivalence are separate decisions: byte equality alone cannot establish read-only behavior, address insignificance, or compatible dynamic binding.

Target-value comparison also includes address arithmetic. Within the same target section, st_value=4, A=-4 and st_value=0, A=0 can identify the same effective offset; the corresponding LLD comparison considers st_value + A. Different symbol names or addends therefore do not automatically imply different results. Permitted normalization depends on relocation semantics and implementation support. Two distinct preemptible symbols cannot be merged merely because their current definitions match.

Function identity is observable

Distinct functions can have equal implementations while their pointers must remain distinguishable. Use a separate caller so the comparison occurs on returned addresses:

1
// ptr.c: can folding change function-pointer equality?
2
int add_i(int a, int b);
3
int (*pick(void))(int, int);
4

5
int main(void) {
6
    int (*p)(int, int) = pick();          // pick returns add_j
7
    return (p == add_i) * 10 + p(1, 2);   // expected without folding: 3
8
}

1
$ link_musl ptr_none icf.o ptr.o
2
$ link_musl ptr_safe icf.o ptr.o --icf=safe
3
$ link_musl ptr_all icf.o ptr.o --icf=all
4
$ for p in ptr_none ptr_safe ptr_all; do ./$p; echo "$p=$?"; done
5
ptr_none=3
6
ptr_safe=3
7
ptr_all=13

--icf=all changes the result from 3 to 13 because the pointers now compare equal. That mode accepts assumptions stronger than ordinary language semantics. A program using function pointers as callback identities or map keys may observe the change.

Safe ICF needs evidence about address significance. Clang's .llvm_addrsig lists symbol-table indexes encoded as ULEB128¹⁸:

1
$ llvm-objdump -s -j .llvm_addrsig icf.o
2
Contents of section .llvm_addrsig:
3
 0000 06                                   .
4
$ readelf -sW icf.o
5
Symbol table '.symtab' contains 8 entries:
6
   Num:    Value          Size Type    Bind   Vis      Ndx Name
7
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
8
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS icf.c
9
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 .text.add_i
10
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 .text.add_j
11
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 .text.pick
12
     5: 0000000000000000     4 FUNC    GLOBAL DEFAULT    3 add_i
13
     6: 0000000000000000     4 FUNC    GLOBAL DEFAULT    4 add_j
14
     7: 0000000000000000     6 FUNC    GLOBAL DEFAULT    5 pick
15
$ ld.lld -e pick --icf=safe --print-icf-sections icf.o -o icf_safe
16
$ nm icf_safe | grep -E 'add_|pick'
17
0000000000201180 T add_i
18
0000000000201190 T add_j
19
00000000002011a0 T pick

Here 06 identifies add_j; the other input marks add_i. LLD keeps address-significant code unique. Taking an address is not automatically the same as requiring a unique identity: the compiler supplies the stronger semantic information it can prove.

If an object has no address-significance table, LLD conservatively treats its symbols as significant. That includes undefined symbols which may resolve to definitions in other objects; protecting only the missing-table object's own sections would be insufficient. Exported dynamic symbols also require conservative treatment. In all mode, executable-code significance is relaxed, while significant read-only data still has identity constraints. ICF eligibility can include suitable constants and exception tables, not just .text.

Equal code also needs compatible unwind descriptions

ICF assigns several input functions one output code range. An unwinder examining a PC in that range must receive recovery rules that apply to the retained code. Equal instructions and references do not justify choosing either input's FDE arbitrarily: CFA rules, register recovery, and exception-handling information from Theory 08 can differ.

Comparing every raw record byte is also insufficiently precise. The FDE's CIE pointer depends on the distance between records, and its initial-location encoding depends on the code and field placements. Equal descriptions stored at different input positions can therefore contain different numbers. These fields connect a record to its subjects; they do not specify how to recover the caller. Placement differences must be separated from description differences.

Consider an explicitly limited model: 32-bit record framing, a four-byte PC-relative initial location, a four-byte address range, and no personality or LSDA. Offsets below are measured from the FDE's start:

Within this model, zeroing FDE bytes [4,12) yields a comparison representation, provided the described section-relative code start is retained separately and the actual CIE contents are compared. Two functions starting at input section offset 0, with matching CIE, range, and CFI, are not rejected merely because their record distances differ. A description using CFA = rsp + 8 cannot be substituted for one using CFA = rsp + 16. A function without an FDE is not automatically unwind-equivalent to one with an FDE.

Exact comparison establishes a conservative relation: distinct encodings might describe equal behavior, but an implementation may decline to fold them. Pointer encodings, personalities, and LSDAs outside the model require further semantic handling or conservative rejection. Deleting unfamiliar information before comparison cannot establish compatibility. Eligibility, reference equivalence, and unwind compatibility must all hold.

After folding, layout retains the representative code and redirects references and symbol entries; unwind emission rebuilds records for that retained code. Debug records must also describe which source-level functions lost independent addresses, as discussed in Theory 11. Input comparison, output layout, and metadata rebuilding are distinct obligations. Reduced code size proves none of them on its own.

Gold's safe ICF predates this table and can use architecture-specific relocation analysis to distinguish calls from address-taking. The native GCC/gold comparison is:

1
$ gcc -O2 -ffunction-sections -c icf.c -o icf_gcc.o
2
$ gcc -O2 -ffunction-sections -c ptr.c -o ptr_gcc.o
3
$ gcc -fuse-ld=gold -Wl,--icf=all -Wl,--print-icf-sections icf_gcc.o ptr_gcc.o -o gptr_all
4
/usr/bin/ld.gold: ICF Converged after 2 iteration(s)
5
/usr/bin/ld.gold: ICF folding section '.text.add_i' in file 'icf_gcc.o' into '.text.add_j' in file 'icf_gcc.o'
6
$ gcc -fuse-ld=gold -Wl,--icf=safe -Wl,--print-icf-sections icf_gcc.o ptr_gcc.o -o gptr_safe
7
/usr/bin/ld.gold: ICF Converged after 1 iteration(s)
8
$ ./gptr_all; echo "gptr_all=$?"
9
gptr_all=13
10
$ ./gptr_safe; echo "gptr_safe=$?"
11
gptr_safe=3
12
$ gcc -fuse-ld=bfd -Wl,--icf=all icf_gcc.o ptr_gcc.o -o gptr_bfd
13
/usr/bin/ld.bfd: unrecognized option '--icf=all'
14
/usr/bin/ld.bfd: use the --help option for usage information
15
collect2: error: ld returned 1 exit status

It makes the same safe/all distinction in this x86-64 example, choosing a different representative without changing the issue. GNU BFD ld rejects the ICF option in the tested configuration.

Unwinding adds another requirement. Identical text can have different LSDA¹⁹ exception actions. LLD excludes code covered by FDEs²⁰ with LSDA rather than merging incompatible runtime descriptions. A correct byte comparator alone is not a correct folding implementation.

One instruction address can describe two source functions

1
$ clang -fno-pie -O2 -g -ffunction-sections -c icf.c -o icf_g.o
2
$ ld.lld -e pick --icf=all icf_g.o -o icf_g_all
3
$ llvm-dwarfdump --debug-info icf_g_all | grep -E 'DW_AT_(name|low_pc)'
4
              DW_AT_name	("icf.c")
5
              DW_AT_low_pc	(0x0000000000000000)
6
                DW_AT_low_pc	(0x0000000000201170)
7
                DW_AT_name	("add_i")
8
                ...
9
                DW_AT_low_pc	(0x0000000000000000)
10
                DW_AT_name	("add_j")
11
                ...
12
                DW_AT_low_pc	(0x0000000000201180)
13
                DW_AT_name	("pick")
14
$ llvm-dwarfdump --debug-addr icf_g_all
15
icf_g_all:	file format elf64-x86-64
16

17
.debug_addr contents:
18
Address table header: length = 0x0000001c, format = DWARF32, version = 0x0005, addr_size = 0x08, seg_size = 0x00
19
Addrs: [
20
0x0000000000201170
21
0x0000000000000000
22
0x0000000000201180
23
]
24
$ llvm-dwarfdump --debug-line icf_g_all | sed -n '/^Address/,$p'
25
Address            Line   Column File   ISA Discriminator OpIndex Flags
26
------------------ ------ ------ ------ --- ------------- ------- -------------
27
0x0000000000201170      2     36      0   0             0       0  is_stmt prologue_end
28
0x0000000000201173      2     27      0   0             0       0
29
0x0000000000201174      2     27      0   0             0       0  end_sequence
30
0x0000000000201170      3     36      0   0             0       0  is_stmt prologue_end
31
0x0000000000201173      3     27      0   0             0       0
32
0x0000000000201174      3     27      0   0             0       0  end_sequence
33
0x0000000000201180      4     31      0   0             0       0  is_stmt prologue_end
34
0x0000000000201186      4     31      0   0             0       0  is_stmt end_sequence

LLD tombstones the folded function's ordinary address metadata, but preserves its line sequence at the surviving code address so source breakpoints remain possible. Reverse symbolization is inherently ambiguous: one physical instruction sequence represents more than one source function. This is deliberate information loss, not necessarily a relocation bug.

Layout can change performance without changing instructions

Function placement affects instruction-cache lines and translation working sets. A hot function sharing lines or pages with cold code can consume more cache and iTLB capacity than the same hot functions clustered together. Static coverage is not a count of actual misses or page faults.

Page coverage, total code size, and address span measure different things. A function at address a with size n > 0 occupies page numbers from floor(a / 4096) through floor((a + n - 1) / 4096). For several functions, coverage is the cardinality of the union of those page numbers. Total code size sums function sizes; span extends from the earliest start to the latest end and includes intervening contents and gaps.

The two functions in the diagram contain 64 bytes in either arrangement. Scattered placement touches two pages, while the intervening page contains no hot code: dividing span by page size would count a different set. Clustered placement touches one page. Alignment can leave gaps even after ordering, so ceil(total hot bytes / page size) is a capacity lower bound rather than the expected coverage. Cache-line coverage uses the same calculation with the selected line size instead of 4096.

LLD accepts --symbol-ordering-file, listing symbols whose input sections should be placed first. Function sections make that control useful. Compiler hot/cold attributes and profiles can also choose section prefixes:

1
// hotcold.c: mark hot and cold paths
2
__attribute__((cold, noinline)) int report_error(int x) { return -x; }
3
__attribute__((hot, noinline)) int fast_path(int x) { return x + 1; }
4
__attribute__((noinline)) int normal(int x) { return x * 2; }
5

6
int main(int argc, char **argv) {
7
    if (argc > 5) return report_error(argc);
8
    return fast_path(argc) + normal(argc);
9
}

1
$ clang -fno-pie -O2 -ffunction-sections -c hotcold.c -o hc_clang.o
2
$ llvm-readelf -SW hc_clang.o | grep -E '\.text'
3
  [ 3] .text.unlikely.report_error PROGBITS 0000000000000000 000040 000005 00  AX  0   0  1
4
  [ 4] .text.hot.fast_path PROGBITS      0000000000000000 000050 000004 00  AX  0   0 16
5
  [ 5] .text.normal      PROGBITS        0000000000000000 000060 000004 00  AX  0   0 16
6
  [ 6] .text.main        PROGBITS        0000000000000000 000070 000025 00  AX  0   0 16
7
$ gcc -O2 -c hotcold.c -o hc_gcc.o
8
$ llvm-readelf -SW hc_gcc.o | grep -E '\.text'
9
[ 1] .text             PROGBITS        0000000000000000 000040 000008 00  AX  0   0 16
10
  [ 4] .text.unlikely    PROGBITS        0000000000000000 000048 00000b 00  AX  0   0  1
11
  [ 5] .text.hot         PROGBITS        0000000000000000 000058 000008 00  AX  0   0 16
12
  [ 6] .text.startup     PROGBITS        0000000000000000 000060 00001c 00  AX  0   0 16
13
  [ 7] .rela.text.startup RELA           0000000000000000 000288 000048 18   I 13   6  8

The GCC section is 0x0b, or eleven bytes. Inspect objdump -dr -j .text.unlikely hc_gcc.o to account for them:

report_error occupies nine bytes and the split cold branch two. This GCC build emits endbr64 by default; the Clang function above lacks those four bytes and occupies five. Do not substitute one compiler's function size into the other object's section table. The .text.startup name is a classification hint, not a file-format requirement that its contents execute exactly once.

Their treatment depends on the linker:

1
$ ld.lld -e main hc_gcc.o -o hc_gcc.o.out
2
$ llvm-readelf -SW hc_gcc.o.out | grep -E '\.text'
3
[ 3] .text             PROGBITS        0000000000201270 000270 00004c 00  AX  0   0 16
4
$ ld.lld -e main -z keep-text-section-prefix hc_gcc.o -o hc_gcc.o.keep.out
5
$ llvm-readelf -SW hc_gcc.o.keep.out | grep -E '\.text'
6
[ 3] .text             PROGBITS        0000000000201270 000270 000008 00  AX  0   0 16
7
  [ 4] .text.unlikely    PROGBITS        0000000000201278 000278 00000b 00  AX  0   0  1
8
  [ 5] .text.hot         PROGBITS        0000000000201290 000290 000008 00  AX  0   0 16
9
  [ 6] .text.startup     PROGBITS        00000000002012a0 0002a0 00001c 00  AX  0   0 16
10
$ llvm-nm -n hc_gcc.o.keep.out
11
0000000000201270 T normal
12
0000000000201278 T report_error
13
0000000000201281 t main.cold
14
0000000000201290 T fast_path
15
00000000002012a0 T main
16
$ ld.bfd -e main hc_gcc.o -o bfd.out
17
$ llvm-nm -n bfd.out | grep -E ' [Tt] '
18
0000000000401000 T report_error
19
0000000000401009 t main.cold
20
0000000000401010 T main
21
0000000000401030 T fast_path
22
0000000000401040 T normal
23
$ ld.bfd --verbose | grep -E 'text\.(unlikely|hot|startup)'
24
    *(.text.unlikely .text.*_unlikely .text.unlikely.*)
25
    *(.text.startup .text.startup.*)
26
    *(.text.hot .text.hot.*)

In this example, LLD normally merges text prefixes into .text; -z keep-text-section-prefix preserves categories such as .text.hot and .text.unlikely as distinct output sections. GNU's default script orders categories within a single text output. GCC also produces startup and split-cold sections in this fixture; Clang's exact classification differs.

A controlled ordering experiment

The generator creates 65,536 functions and selects one in every 16 as hot, giving 4,096 hot functions. The same object is linked with default and clustered ordering:

1
clang -O2 -fno-pie -ffunction-sections -DITER=4000 -c prog.c -o prog.o
2
clang -fuse-ld=lld -static prog.o -o p_default
3
clang -fuse-ld=lld -static prog.o -Wl,--symbol-ordering-file=hot.txt -o p_ordered
4
python3 pages.py p_default p_ordered

1
p_default  hot code 106516 bytes, span 2555913 bytes,521 pages,4546 cache lines
2
p_ordered  hot code 106516 bytes, span 159763 bytes,40 pages,2497 cache lines

pages.py uses actual symbol addresses and sizes from llvm-nm -S. Both layouts contain 106,516 hot-code bytes. Default placement spans 2,555,913 bytes, 521 pages, and 4,546 cache lines; clustering spans 159,763 bytes, 40 pages, and 2,497 lines. These are geometric coverage counts for 4 KiB pages and 64-byte lines, not measured hardware events.

Eight alternated timing rounds checked return code 79 each time. Median native time was 0.3340 seconds for default order and 0.1085 for clustered order. The synthetic arrangement makes the effect unusually clear. Without counters, it cannot attribute the entire difference to a particular cache, iTLB, or predictor mechanism. Page faults, hardware misses, and simulator counts must be reported separately if later measurements add them.

Profiles can drive ordering in real programs. BOLT rewrites linked binaries, including basic-block placement. Propeller arranges for finer-grained compiler sections and profile-directed relinking. Both need workload evidence; layout is not improved merely by making a list look tidy.

The example provides another view of section contents and relocation targets.

Exercises

Use the commands above to link and run the Linux fixtures directly on Linux; no emulator is implied.

1. Separate the stages. Relink the first pair of LLVM objects with --lto-O0. Which of main, scale, twice, and checksum survive, and is there still a call? Then give GCC fat LTO objects to LLD. Does that link perform GCC LTO?

2. Predict equivalence and significance. Compile this input with -O2 -ffunction-sections:

1
// taken.c
2
typedef int (*fn)(int);
3
int h1(int x) { return x ^ 0x55; }
4
int h2(int x) { return x ^ 0x55; }
5
int h3(int x) { return x ^ 0x55; }
6
int h4(int x) { return x ^ 0x55; }
7
fn table[] = { h2, h4 };
8
int main(int argc, char **argv) { return h1(argc) + h3(argc) + table[argc & 1](argc); }

1
Contents of section .llvm_addrsig:
2
 0000 080a                                 ..
3
     7: 0000000000000000     6 FUNC    GLOBAL DEFAULT     3 h1
4
     8: 0000000000000000     6 FUNC    GLOBAL DEFAULT     4 h2
5
     9: 0000000000000000     6 FUNC    GLOBAL DEFAULT     5 h3
6
    10: 0000000000000000     6 FUNC    GLOBAL DEFAULT     6 h4
7
    11: 0000000000000000    24 FUNC    GLOBAL DEFAULT     7 main
8
    12: 0000000000000000    16 OBJECT  GLOBAL DEFAULT     9 table

Decode the significance table, predict safe/all folding of the .text.* sections, and calculate ./taken_all a's exit code. For this fixture, stable ordering selects the earliest eligible input as representative.

Next compile this recursive example at -O0 -ffunction-sections:

1
// mutual.c
2
int b(int x);
3
int a(int x) { return x ? b(x - 1) * 3 : 1; }
4
int b(int x) { return x ? a(x - 1) * 3 : 1; }
5
int c(int x) { return x ? c(x - 1) * 3 : 1; }
6
int d(int x) { return x ? a(x - 1) * 5 : 1; }
7
int main(int argc, char **argv) { return a(argc) + b(argc) + c(argc) + d(argc); }

The bytes of a, b, and c match, but their relocations point to b, a, and c. d has different multiplication. Refine the equivalence classes round by round. What goes wrong if target names enter the equivalence key? Safe mode receives significance indexes 07 08 09 0a for all four functions.

3. Repair a runtime export. Build the host with LTO and load the plugin natively with the configured musl runtime:

1
// host.c: the host provides plugin_hook for runtime lookup
2
#include <dlfcn.h>
3
#include <stdio.h>
4

5
int plugin_hook(int x) { return x + 100; }
6

7
int main(void) {
8
    void *h = dlopen("./plugin.so", RTLD_NOW);
9
    if (!h) { printf("dlopen: %s\n", dlerror()); return 1; }
10
    int (*run)(int) = (int (*)(int))dlsym(h, "plugin_run");
11
    printf("plugin_run(1) = %d\n", run(1));
12
    return 0;
13
}

1
// plugin.c: build as plugin.so
2
int plugin_hook(int x);
3
int plugin_run(int x) { return plugin_hook(x) * 2; }

Predict the failure without export options. Does used fix it? Give two linking solutions. Does disabling LTO alone fix it?

Answers

1. Liveness, internalization, and inlining are separate

1
$ link_musl lto_o0 main.lto.o util.lto.o --lto-O0
2
$ llvm-nm -S lto_o0 | grep -E ' (main|scale|twice|checksum)$'
3
0000000000201a10 0000000000000032 T main
4
0000000000201a50 0000000000000006 t scale
5
$ llvm-objdump -d --no-show-raw-insn --disassemble-symbols=main lto_o0 | grep call
6
201a25:      	callq	0x201a50 <scale>

twice and checksum are already excluded by liveness before the ordinary optimization pipeline. scale survives as local t, proving internalization happened, but the call remains because inlining did not. main remains 0x32 bytes.

1
$ link_musl fat main.fat.o util.fat.o
2
$ llvm-nm -S fat | grep -E ' (main|scale|twice|checksum)$'
3
0000000000201340 000000000000003e T checksum
4
00000000002012d0 0000000000000031 T main
5
0000000000201320 0000000000000009 T scale
6
0000000000201330 0000000000000008 T twice

All four functions survive in the GCC-fat/LLD case. LLD uses the embedded machine code and ignores excluded GIMPLE sections. The surviving call and unused definitions reveal the fallback. LLVM's own fat-object support is a different format and option; it does not make GCC GIMPLE readable to LLD.

2. Follow classes, not spelling

Indexes 8 and 10 identify h2 and h4. Safe mode protects them and merges h1 with h3; all mode merges all four:

1
$ link_musl taken_safe taken.o --icf=safe --print-icf-sections 2>&1 | grep -A3 'taken.o:(.text.'
2
selected section taken.o:(.text.h1)
3
  removing identical section taken.o:(.text.h3)
4
$ link_musl taken_all taken.o --icf=all --print-icf-sections 2>&1 | grep -A3 'taken.o:(.text.'
5
selected section taken.o:(.text.h1)
6
  removing identical section taken.o:(.text.h2)
7
  removing identical section taken.o:(.text.h3)
8
  removing identical section taken.o:(.text.h4)

With argc = 2, each call returns 2 ^ 0x55 = 87; three calls total 261, whose low byte is 5. The program never compares function pointers, so both layouts return 5.

For recursion, initially group {a,b,c}, {d}, and {main}. The three matching sections all relocate to the first class, so no refinement separates them:

1
selected section mutual0.o:(.text.a)
2
  removing identical section mutual0.o:(.text.b)
3
  removing identical section mutual0.o:(.text.c)
4
$ llvm-nm mutual0 | grep -E ' [abcd]$' | sort
5
00000000002012b0 T a
6
00000000002012b0 T b
7
00000000002012b0 T c
8
00000000002012f0 T d

Hashing target names would unnecessarily split all three. Refinement instead asks whether the current equivalence assumption remains self-consistent. The folded and unfolded examples return 14 with no extra argument and 42 with one. Safe mode folds none because all four are listed as significant. At -O2, compiler transformations and address metadata differ, which is why this structural exercise specifies -O0.

3. Retaining a symbol is not exporting it

1
h_plain symtab=1 dynsym=0
2
h_lto symtab=0 dynsym=0
3
h_lto_used symtab=1 dynsym=0
4
h_lto_E symtab=1 dynsym=1
5
h_lto_dl symtab=1 dynsym=1
6
== h_lto
7
dlopen: Error relocating ./plugin.so: plugin_hook: symbol not found
8
== h_lto_used
9
dlopen: Error relocating ./plugin.so: plugin_hook: symbol not found
10
== h_lto_E
11
plugin_run(1) = 202
12
== h_lto_dl
13
plugin_run(1) = 202
14
== h_plain
15
dlopen: Error relocating ./plugin.so: plugin_hook: symbol not found
16
== h_plain_E
17
plugin_run(1) = 202

Without exports, dlopen(..., RTLD_NOW) cannot resolve the plugin's reference in the host's dynamic symbol table. LTO additionally removes the unreferenced definition. used restores it to .symtab but does not put it in .dynsym, so runtime lookup still fails.

--export-dynamic exports eligible globals; --dynamic-list=dyn.list, with { plugin_hook; };, selects the hook. Both also tell LTO that the symbol is externally visible. The repaired program prints 202. Disabling LTO alone leaves a normal symbol but still no dynamic export, so it does not repair the underlying contract.