Hacker News Reader

Am I missing something, or is their example at the start of section 3 (bottom of page 7) plain wrong? If x is an uint32_t, then ((x << 31) >> 31) + 1 returns either 1 or 2; while the "optimized" version ~x&1 reutrns 1 or 0 (which matches the semantics they describe, while the initial code does not).

View on HN

If you look at the llvm IR, it is using ashr (arithmetic shift), so you can probably assume this isn't targeting unsigned types

The text also explicitly states this is about signed integers: ”let’s look at taking ((x << 31) >> 31) + 1, an inefficient idiom for isolating and flipping the low bit of a signed 32-bit integer”

I think there is an error on page 9, though: ”Second, −a+−b can be rewritten as −(a − b)”. I think that should be either a left-hand side of ”-a--b” or a right-hand side of ”-(a + b)”.

Reply on news.ycombinator.com