Codegen significantly worse when using u128 rather than two u64 about rust HOT 3 OPEN

The operation is not actually the same. The behaviour of the u128 version is different from the custom version when bits is more than 64, as it correctly shifts bits from the upper 64 bits into the lower ones, whereas in the custom version, you get some very weird behaviour.

from rust.

This function is always inlined in functions where num_bits is way less than 64, usually at most 4, and codegen actually gets worse when I add assert!(num_bits < 64);. I would expect the compiler to be able to optimize based on the constant the function gets called with, since it is always known at compile time.

from rust.

@linkmauve at least for obvious examples where n_bits is a compile-time constant, it does appear that the compiler avoids cmov sequences when it can also prove n_bits < 64. Even where it is not known at compile-time, if you explicitly mask n_bits by 63, this also allows it to avoid cmov sequences (godbolt).

The fact that assert!() doesn't help here is unfortunate (I even tried using unreachable_unchecked() to force the generation of a llvm.assume but that also didn't help) -- most likely there is room for improvement in LLVM's lowering of shr on types with bitwidth > 64.

from rust.