News for hackers. Stuff that matters.
Re:Catching integer overflows in C by lyinsteve on Wednesday August 22, 2018 @12:12AM (#17816237)
I don’t know much about rust specifically, but the overflow traps happen in debug (i.e. -O0) builds, and are not emitted when optimizations are enabled.

LLVM’s constant folding and canonicalization passes will convert (x * 2) / 2 from

%0 = mul i64 %x, i64 2

%1 = div i64 %0, i64 2

to

%0 = shl i64 %x, i64 1

%1 = shr i64 %0, i64 1

Which constant folding will reduce to just %x.

Re:Catching integer overflows in C by BeeOnRope on Wednesday August 22, 2018 @03:12AM (#17816934)
How do the two shifts reduce to x? The top bit is zeroed as a result of those shifts.
Re:Catching integer overflows in C by millstone on Wednesday August 22, 2018 @12:57AM (#17816422)
Well ok but (x*3)/3 will be a lot worse :)
Re:Catching integer overflows in C by Franciscouzo on Wednesday August 22, 2018 @01:30AM (#17816525)
Not by a lot, the divide by constant can be optimized to a multiplication, if you're doing it in a loop (why would you care if you do it only once), you can reach a throughput of one multiplication per cycle, so (x*3)/3 would take 2 cycles on average.
Re:Catching integer overflows in C by millstone on Wednesday August 22, 2018 @03:05AM (#17816909)
This is a silly line of argument; optimizing (x*3)/3 to x unlocks further CSE, inlining, etc. so the benefit may be arbitrarily large.

Rust made the right tradeoff here but it is a tradeoff!