On Wed, Mar 29, 2023 at 10:20 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Wed, 2023-03-29 at 10:05 -0700, Nathan Chancellor wrote: > > > > GCC has optimizations for division by a constant that clang does not > > implement, so this issue is not visible when building with GCC. > > Huh yeah, we did 32-bit builds with gcc ... Right, GCC is better about turning division by double-word constant into multiplication by reciprocal. Craig has been improving LLVM, but it seems that some divisors still aren't supported (in this case 100). > > > Using div_u64() would resolve this issue, but Arnd points out that this > > can be quite expensive and the timestamp is being read at nanosecond > > granularity. > > Doesn't matter though, all the calculations are based on just the > command response from the firmware, which (tries to) take it in a > synchronised fashion. > > So taking more time here would be fine, as far as I can tell. div_u64() it is then. > > > Nick pointed out that the result of this division is being > > stored to a 32-bit type anyways, so truncate gp2_10ns first then do the > > division, which elides the need for libcalls. > > That loses ~7 top bits though, no? I'd be more worried about that, than > the time div_u64() takes. The result is still stored in a u32; there is a loss of precision regardless of use of div_u64 or open coded binary operator /. So is the loss of precision before the division as tolerable as after the division? -- Thanks, ~Nick Desaulniers
