[PATCH] D141798: Remove ZeroBehavior of countLeadingZeros and the like (NFC)

[Kazu Hirata via Phabricator via cfe-commits]

kazu created this revision.
Herald added subscribers: Moerafaat, zero9178, bzcheeseman, kosarev, sdasgup3, wenzhicui, wrengr, ormris, foad, cota, teijeong, frasercrmck, rdzhabarov, tatianashp, msifontes, jurahul, Kayjukh, grosul1, Joonsoo, kerbowa, liufengdb, aartbik, mgester, arpith-jacob, csigg, antiagainst, shauheen, rriddle, mehdi_amini, luismarques, apazos, sameer.abuasal, pengfei, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, niosHD, sabuasal, simoncook, johnrusso, rbar, asb, hiraditya, arichardson, jvesely, arsenm.
Herald added a project: All.
kazu requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, pcwang-thead, stephenneuendorffer, nicolasvasilache, MaskRay.
Herald added projects: clang, MLIR, LLVM.

This patch removes ZeroBehavior from bit counting functions like
countLeadingZeros and findFirstSet.  ZeroBehavior specifies the
behavior when the input to count{Leading,Trailing}Zeros is zero and
when the input to count{Leading,Trailing}Ones is all ones.

ZeroBehavior was first introduced on May 24, 2013 in commit
eb91eac9fb866ab1243366d2e238b9961895612d.  While that patch did not
state the intention, I would guess ZeroBehavior was for performance
reasons.  The x86 machines around that time required a conditional
branch to implement countLeadingZero that returns the
std::numeric_limits<T>::digits on zero:

  test    edi, edi
  je      .LBB0_2
  bsr     eax, edi
  xor     eax, 31

.LBB1_2:

  mov     eax, 32

That is, we can remove the conditional branch if we don't care about
the behavior on zero.

IIUC, Intel's Haswell architecture, launched on June 4, 2013,
introduced several bit manipulation instructions, including lzcnt and
tzcnt, which eliminated the need for the conditional branch.

I think it's time to retire ZeroBehavior as its utility is very
limited.  If you care about compilation speed, you should build LLVM
with an appropriate -march= to take advantage of lzcnt and tzcnt.
Even if not, modern host compilers should be able to optimize away
quite a few conditional branches because the input is often known to
be nonzero from dominating conditional branches.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D141798

Files:
  clang/lib/CodeGen/SwiftCallingConv.cpp
  llvm/include/llvm/Support/MathExtras.h
  llvm/lib/Target/AMDGPU/AMDGPUCallLowering.cpp
  llvm/lib/Target/AMDGPU/SIISelLowering.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVMatInt.cpp
  llvm/lib/Transforms/IPO/LowerTypeTests.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  mlir/lib/Bytecode/Reader/BytecodeReader.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D141798.489376.patch
Type: text/x-patch
Size: 12790 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20230115/685ee580/attachment-0001.bin>