Every working programmer has been bitten by the impossible bug: code that hasn't been touched in months suddenly slows down or breaks after a seemingly unrelated change. Usually we shrug, blame the build cache, and move on. This post does the rare and valuable thing of chasing the rabbit all the way down to the silicon.

Based on the title, the author traces a performance regression in untouched code to an L1 instruction-cache associativity conflict. For readers who haven't thought about cache architecture since university, here's why that's a fascinating culprit:

• L1 caches aren't fully associative. They're typically organized as N-way set-associative structures, meaning addresses that map to the same set compete for a limited number of "ways."
• If too many hot code paths happen to land at addresses that hash to the same set, you get conflict misses even though the total working set fits comfortably in cache.
• Changing unrelated code — adding a function, reordering a translation unit, even a linker tweak — can shift the layout of your binary by a few bytes and push previously-harmonious hot paths into the same cache set.

This is the kind of bug that makes you question your sanity. Your diff is empty. Your benchmarks regressed. The compiler version didn't change. And yet the CPU is quietly evicting your hottest instructions on every loop iteration because the linker decided to lay out your code two bytes differently.

What makes posts like this valuable for a technical audience:

• Methodology over conclusion. Diagnosing this requires perf counters (specifically L1-icache-load-misses), understanding how to read PMU events, and being willing to consider that the problem is below your code rather than in it.
• Mental model expansion. Most engineers know data caches matter. Far fewer think about instruction cache pressure, which becomes a real issue in large C++ codebases, JIT-heavy runtimes, and hot interpreter loops.
• It's a reminder that performance is non-local. Modern hardware makes the lie of "you only need to think about your own function" increasingly expensive.

If you've ever wondered why -falign-functions exists, why some teams obsess over link order, or why Facebook built tools like BOLT to reorder hot code after profiling — this is the underlying phenomenon that motivates all of it.