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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
34045 | 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? |
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.
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
34045 | 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. |
llvm/lib/Target/X86/X86ISelLowering.cpp | ||
---|---|---|
34045 | 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. |
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?