The behavior is undefined for an input of 0, otherwise the result
is the position of the most significant set bit which must be in
the range [0, bitwidth-1]. So any bits above log2 of bitwidth
must be 0.
|3,910 ms||windows > Clang-Unit.DirectoryWatcher/_/DirectoryWatcherTests_exe::DirectoryWatcherTest.AddFiles|
Note: Google Test filter = DirectoryWatcherTest.AddFiles [==========] Running 1 test from 1 test case.
|3,780 ms||windows > Clang-Unit.DirectoryWatcher/_/DirectoryWatcherTests_exe::DirectoryWatcherTest.DeleteFile|
Note: Google Test filter = DirectoryWatcherTest.DeleteFile [==========] Running 1 test from 1 test case.
|3,800 ms||windows > Clang-Unit.DirectoryWatcher/_/DirectoryWatcherTests_exe::DirectoryWatcherTest.ModifyFile|
Note: Google Test filter = DirectoryWatcherTest.ModifyFile [==========] Running 1 test from 1 test case.
Technically yes, we just didn't have test coverage for it. Probably because we only use X86ISD::BSF when we immediately emit a CMOV for CTTZ and we need to connect the flag output. For CTTZ_ZERO_UNDEF we match BSF in isel patterns.
The case I was trying to fix was this cross basic block case from the OPTIMIZE version of https://skanthak.homepage.t-online.de/llvm.html#case21
I doubt KnownNeverZero would work since its control flow dependent and it looks like the SelectionDAG implementation is only handles non-zero constants or an OR involving a non-zero constant.
Sorry - I forgot about this! I think you're right in that in all the cases where X86ISD::BSR is generated, we have suitable zero-input handling in place - either we already treat this as CTLZ_ZERO_UNDEF (which computeknownbits already reports the same result for) or its part of an CTLZ and LowerCTLZ added zero-input wrapping already.
I'd feel better with a bit more of an explanation comment about our assumptions, but otherwise looks ok.