> 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)
