Page MenuHomePhabricator

[X86] Add basic computeKnownBits support for X86ISD::BSR
Needs ReviewPublic

Authored by craig.topper on Oct 11 2020, 2:27 PM.



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.

Diff Detail

Unit TestsFailed

3,910 mswindows > Clang-Unit.DirectoryWatcher/_/DirectoryWatcherTests_exe::DirectoryWatcherTest.AddFiles
Note: Google Test filter = DirectoryWatcherTest.AddFiles [==========] Running 1 test from 1 test case.
3,780 mswindows > Clang-Unit.DirectoryWatcher/_/DirectoryWatcherTests_exe::DirectoryWatcherTest.DeleteFile
Note: Google Test filter = DirectoryWatcherTest.DeleteFile [==========] Running 1 test from 1 test case.
3,800 mswindows > Clang-Unit.DirectoryWatcher/_/DirectoryWatcherTests_exe::DirectoryWatcherTest.ModifyFile
Note: Google Test filter = DirectoryWatcherTest.ModifyFile [==========] Running 1 test from 1 test case.

Event Timeline

craig.topper created this revision.Oct 11 2020, 2:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 11 2020, 2:27 PM
craig.topper requested review of this revision.Oct 11 2020, 2:27 PM
RKSimon added inline comments.Oct 12 2020, 8:15 AM

I'm a bit worried about not handling the src==0 undef case - how well does this work if we guarded it with a KnownNeverZero check?

Also, can BSF be handled here as well?

Also, can BSF be handled here as well?

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

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.

RKSimon added inline comments.Jul 24 2021, 7:04 AM

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.