Whole-Program & Feedback-Directed Optimization
Seeing across module boundaries with LTO, and measuring before optimizing with PGO — including what an unrepresentative profile does to the result.
Seeing every function at once turns three transformations from impossible to routine — cross-module inlining, devirtualization and dead-function elimination — by supplying the one thing separate compilation deliberately withheld: the rest of the program.
LTO is a scheduling trick, not a new optimization: the compiler writes IR into object files instead of machine code, and the linker — the first component that has all of them — hands them back to the optimizer before generating any.
Compile once with counters, run a realistic workload, feed the counts back, compile again. The optimizer stops guessing which branch is taken and which function is hot — and the largest real win is usually not what people expect.
A profile is not neutral evidence. An unrepresentative one does not fail to help — it actively points the optimizer at the wrong code, and it decays quietly as the source moves underneath it.
PGO and a JIT are the same idea run at different times. Both optimize from measured behavior; the only two things that differ are when the evidence is collected and whether a guard is needed to act on it.
A compiler is judged on four axes that trade against each other — compile time, memory, incremental turnaround and generated code quality — and the first one changes how engineers work, not merely how long they wait.