@AlexGuteniev I have pushed a merge with main, containing major changes to <limits>. I believe that this preserves the intent of your changes, while applying them to the post-#2333 codebase, refactoring the logic to be cleaner (particularly around the widen-8/16-bits logic), and further enhances the nonzero optimization (in particular, we can avoid inspecting BSF's return value).

Please let me know if anything looks weird/wrong!

Please let me know if anything looks weird/wrong!

I think it is correct, but looks like without attempting to use tzcnt as bsf the intent may need reconsideration.

As the change was originally written, it avoided branches. The branches were there only for zero input.
Now there is a branch between tzcnt and bsf, regardless of zero/nonzero. And bsf itself is branchless (it uses cmov).
And bsf is a fallback.

So currently the change appears to be near-zero improvement, that doesn't even worth complicating code.

Need to benchmark and inspect codegen to figure out what should be done. Maybe implementing the same thing as for vector<👻>. Maybe just implementing #2133 will do (then again, this change may be useful, but may be not).

This optimization makes gcd 1 to 2 percent faster.
I've tried alternative approach (similar to _Select_popcount_impl), it turned out to be slightly faster than this one, still between 1 and 2 percent faster than the current.
Do we want to proceed?

1-2% is worth it, I think (it's pretty small on the scale of libs performance improvements, but it's easily something that the backend team would celebrate as their codegen is already highly optimized, and improving program perf without user-programmer intervention is always nice). @barcharcraz agrees - let's proceed!

Please consider submitting #2343 instead of this one.
It:

• Gives slightly better results
• Easier to explain the optimization
• Consistent with similar optimization for _Popcount

Looking at #2343, I agree that it appears to be superior. Closing this PR.