Remove attempt to use tzcnt as bsf

[AlexGuteniev]

Resolves #2330
Fixes VSO-1434895/AB#1434895.

[barcharcraz]

How different is the codegen between the bsf version and the tzcnt version?

This is kinda pre-existing but we should do some benchmarks to determine if it's even worth doing the tzcnt version if we need to dynamically check for it.

[AlexGuteniev]

but we should do some benchmarks to determine if it's even worth doing the tzcnt version if we need to dynamically check for it.

We'll track this as #2133

[AlexGuteniev]

How different is the codegen between the bsf version and the tzcnt version?

Remember bsf requires a branch for zero input

[AlexGuteniev]

@StephanTLavavej no, this wasn't really caused by #1540. Maybe some specific case was triggered by #1540, but the bug was always there since counr_zero implementation.

[StephanTLavavej]

@AlexGuteniev Thanks, I was confused! I've restored your PR description.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

Thanks for investigating and fixing this bug! 🐞 0️⃣ 1️⃣

[AlexGuteniev]

Fixed a bug affecting older CPUs where the STL generated the newer tzcnt instruction instead of the fallback bsf instruction. This affected 's countr_zero() and countr_one(), 's gcd() and lcm(), and vector's optimized implementations of find() and relational/spaceship operators. #2333

This is too aggressive. I mean probably gcd and lcm and vector are fine. For this bug to manifest we would need to immediately compare the result against zero. See @statementreply 's demo: https://godbolt.org/z/aPjnojjcx

I would have said "This affected 's countr_zero() and countr_one(), and potentially ..."