https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125970
--- Comment #5 from cuilili <lili.cui at intel dot com> --- > Yes this matches my observations. If we want to stop "cmov" generation, for > this case, I can think of high-level heuristics like the candidate cmov > result is used to further index in loads/stores or feeds another cmov in a > loop. Right — in this case we can't observe the cmov result feeding another cmov: r10 is broken twice (mov %esi,%r10d, then seta), so the two cmovs aren't chained. But your heuristic is still reasonable in general: if they were chained, it would form a long, non-speculatable dependence chain, in some cases maybe bad. The reason cmov doesn't help here is simply that the branch is highly predictable (~99%), so speculation almost never fails and the branch keeps address generation off the critical path. If the branch were poorly predicted, the same "result feeds an address" pattern would favor cmov instead， because speculative accesses on the wrong path must be squashed, and it would be more expensive than usual.
