My understanding is that profile-guided optimisation is largely based on the utility of small binaries, by optimising hotspots for speed and everything else for space, thereby alleviating cache-pressure. Is this wrong?
> You also won't easily predict the behavior due to reordering.
I wasn't thinking of anything as sophisticated as looking at specific flows, where I can well imagine things get unpredictable with reordering and speculative execution. Won't there will be a reliable pattern of better fitting in cache, if we shrink everything?
IE you couldn't pull in function A without pulling in function B. That is mostly not true[1].
This is why reordering mostly brings load time benefits instead of run time benefits.
The utility of PGO is mostly about knowing where to spend your time optimizing, and knowing what to do. That's a generalization. There are certainly cases in inline/etc heavy code where it helps get the speed part right too. A lot of that is more often about "it lets the compiler spend it's inlining budget on inlining stuff that matters" than "it stops the compiler from blowing cache out".
I speak in generalities because there are always counterexamples.
There are cases where PGO makes things significantly worse, for example!
Last I remember (My job now means i don't have time to stay in the game), LLVM did not bother to optimize the cold regions for size, and GCC did.
[1] It depends on function sizes and page sizes and mlocking and section flags and all sorts of fun things, but i'm just going to assert the truth of this in most cases go make it simpler.
They are mostly unrelated to overall binary size due to paging, etc.
You also won't easily predict the behavior due to reordering.