> Its intentionally uint64, per this comment above it: > > * Note we utilize unsigned integers even though ticks are stored as a signed > * value to encourage compilers to generate better assembly, since we can be > * sure these values are not negative. > > In my earlier Compiler Explorer tests that did actually make a > difference for the generated assembly.
Isn't that comment more about ticks_per_ns_scaled? For max_ticks_no_overflow the only use is with a cast to int64, so I didn't expect much assembly difference. Now I actually checked locally/godbolt, and I don't see any actual differences. Making max_ticks_no_overflow int64 and removing that cast generates exactly the same code. For ticks_per_ns_scaled, gcc 9-10 actually generates +1 mov instruction with int64, but that's not present in more recent versions. Recent compiler versions only have an idiv/div and shr/sar difference. Idiv is slower than div on intel, so that is a point for keeping ticks_per_ns_scaled unsigned. For arm I see the same lsr/asr and udiv/sdiv difference. https://godbolt.org/z/4r5GTbrs3 (the main gcc vs clang difference seems to be clang's 32 bit division optimization)
