3 ms·

There is an undefined behavior in the compiler and an undefined behavior in the CPU. For example, bsr/bsf instructions (count leading or trailing bits) have un

There is an undefined behavior in the compiler and an undefined behavior in the CPU. For example, bsr/bsf instructions (count leading or trailing bits) have undefined behavior if the argument is zero. What I observed is that the CPU leaves the destination register unchanged in this case (but it can do something else according to the spec, for example - set it to zero). The compiler exposes these instructions for convenience as intrinsics __builtin_clz/__builtin_ctz, which consequently, have undefined behavior if the argument is zero. But you can use them directly as an optimization if you know in advance that the argument is non-zero: https://github.com/ClickHouse/ClickHouse/blob/c0a43df749c827ce13abb015faca4ad8ab524685/src/Common/BitHelpers.h#L35 https://github.com/ClickHouse/ClickHouse/blob/c0a43df749c827...

Findecanor 3y ago
`bsr` and `bsf` have "undefined" results on a zero argument in Intel's documentation. In AMD's documentation however, the destination is supposed to be "unchanged". What is unusual is that the 32-bit flavours of these instructions leave the upper 32 bits unchanged, whereas other 32-bit integer instructions write zeroes there even if the lower bits in the destination are unchanged. Perhaps Intel intends to make these instructions zero-extend in the future ... or does there exist some processor (from Intel or someone else) that zero-extends?
- userbinator 3y ago
  In at least the early days of x86, it was common for AMD to document what Intel left undefined: https://news.ycombinator.com/item?id=25320603 https://news.ycombinator.com/item?id=25320603