On 09/11/2015 14:30, Peter Maydell wrote:
> After a bunch of "try building specific object files with optimization
> off to see where the problem goes away" tests, I've narrowed the
> problem down further: if you tell clang to disable optimization by
> adding __attribute__ ((optnone)) to the two functions
> hpet_time_after() and hpet_time_after64() in hw/timer/hpet.c then
> the problem goes away.
>
> My current theory is that we're doing something here that's not
> valid C and the compiler ends up optimizing it into something
> that results in the timer setting the next-timeout to a very
> short interval and that's what's hogging the main-loop time.
> I'll look in more detail after lunch.
The obvious way to write those functions would be
static uint32_t hpet_time_after(uint64_t a, uint64_t b)
{
return ((int32_t)(b - a)) < 0;
}
static uint32_t hpet_time_after64(uint64_t a, uint64_t b)
{
return ((int64_t)(b - a)) < 0;
}
Paolo
