4 ms·
Note that this is only for the direct shift instructions. Some other related instructions, and SIMD versions, might be different from the regular shifts on the
by dzaima 3y ago
Note that this is only for the direct shift instructions. Some other related instructions, and SIMD versions, might be different from the regular shifts on the same architecture.
x86-64's 'bzhi' instruction (does 'a & ((1<<b) - 1)') uses mod 256 (and thus, if mod 32/64 was specified in C, compilers couldn't optimize to this).
ARM NEON's SIMD shifts merge both left and right shift in one instruction (reads low 8 bits as a signed int, positive being left shift, and negative - right shift)
- lifthrasiir 3y ago> if mod 32/64 was specified in C, compilers couldn't optimize to this This reads a bit ambiguously, though the conclusion would be same. If C specification had that requirement, yeah, they have to do mod 32/64 every time integers with unknown bounds are used for `b`. But then Intel should have noticed this first and define LZHI to use mod 32/64 according to the operand, or make two versions of LZHI. If C code had that requirement, for example, by always using `a & ((1 << (b & 31)) - 1)` to avoid an UB, compilers indeed would not be able to optimize it into a single BZHI. But they can use AND+BZHI, and I think BZHI has only a half of throughput than AND in almost all supported processors, so an excess AND probably can't do much harm.
- dzaima 3y agoTrue, Intel could've been influenced if there was an expectation on the behavior of shifts. But I doubt they'd have made two versions, and we'd just be stuck with the less useful mod 32/64 one.