Re: bug fix for hp-timing.h (aarch64)

[Wilco Dijkstra <Wilco.Dijkstra@arm.com>]

Hi Zack,

> I'm surprised to hear you say that.  To me, 16 seconds is an absurdly _long_
> interval for use of hp-timing.h.  For anything longer than a few tens of
> milliseconds, the overhead of two system calls is negligible, but both CPU
> frequency changes and getting descheduled in the middle of the
> measurement become serious concerns.  So it seems more appropriate to
> me to use clock_gettime with a per-process or per-thread clock ID for
> measurements on the scale of tens of seconds.

On AArch64 the counter is absolutely solid - it's fixed frequency and system
wide monotonically increasing. So there are no issues with varying clock
frequency or rescheduling to a different core, you get elapsed time at
nanosecond accuracy.

With such a high quality counter it seems a waste to allow it to overflow
after a short time when there is a simple way to avoid it. Note we could
remove the volatile from the asm as that would allow more lifting of the
cntfreq and start the FP division earlier.

Cheers,
Wilco