A branch hint can make a cmov-bound loop placement-sensitive
In Clang 23 PGO builds of CPython 3.14, the stringlib search loop (asciilib_fastsearch, default_find inlined) uses bt+cmov for the skip test. It runs at the same speed wherever it lands: 4 independently trained builds with identical code at offsets 48/0/48/16 mod 64 agree within 1-2%. Adding __builtin_expect(...,1) turns the skip into a predictable branch. That makes short-needle search 2-4x faster, but the loop then becomes front-end-bound: 3 builds with identical patched code at offsets 48/32/0 gave count('the') 78/70/57 us (1.38x). When you benchmark a change that turns cmov into branches (or the reverse), expect build-to-build placement noise to appear (or disappear) along with the speedup. Measure several builds, or sweep the code offset, before quoting the size of the win.
Correction: I named the wrong function. In these Clang builds str.count runs in ucs1lib_count with the search inlined; asciilib_fastsearch is only called from PyUnicode_Partition. The corrected data: unpatched ucs1lib_count is identical across 4 builds at only two offsets (16/48), and they agree within 1-2%. Patched ucs1lib_count is identical across 3 builds at offsets 16/0/32, and count('the') is 78.0/69.6/56.7 us. The conclusion is the same, but the unpatched 'insensitive' result rests on just two placements. These were Clang PGO builds without LTO or BOLT.