[llvm] [SelectOpt] Don't convert constant selects to branches. (PR #110858)

[David Green via llvm-commits]

davemgreen wrote:

> Makes sense to specialize for constant values but the condition cost also matters. With a select the condition is on the critical path, while with a branch computing the condition is not blocking the instruction. Enabling it in a target-independent manner makes sense but a bit worried about any potential downsides. Was this change motivated by performance diff on some workload/microbenchmark?

Hi. Yeah we found a case where performance was getting worse. I think the new test case captures what was happening, although the real example is a little more complex and had two selects in the loop.

The places where I've seen selectopt really help is where there are cross iteration dependency chains through the select, and a huge dependency chain gets created for the select version that is broken by converting it to a branch. Or if less instruction can be executed thanks to moving instructions into the then/else branch. If both the operands of the select are constant (or I guess loop invariant might be more accurate?) then the same long chains can't happen and the out of order engine should be fine working through the independent iterations. The branch has a higher chance of slowing things down if it gets mis-predicted.

That is my hope at least. I ran some benchmarks and they performed OK overall, giving a 0.8% improvement in geomean for the benchmarks that changed over llvm-test-suite + various version of spec + some other internal benchmarks which all run at the same time. But SelectOpt is going to be relatively noisy as it depends so heavily on the predictability of the branch and how well the branch predictor manages to behave.

https://github.com/llvm/llvm-project/pull/110858