On Wed, Oct 07, 2009 at 07:34:58PM +0200, Andreas Mohr wrote:
> Nopeee.
>
> data->predicted_us = DIV_ROUND_CLOSEST((u32)
> data->expected_us * data->correction_factor[data->bucket],
> (u32)RESOLUTION * DECAY);
>
> It did properly rebuild drivers/cpuidle/governors/menu.o.
> Still happening.
> IOW it must be somewhere inside the DIV_ROUND_CLOSEST macro or so.
>
It's being a jerk and not realizing that RESOLUTION * DECAY is a power
of 2, so it can just do a shift...
I don't recall if gcc 3 had these magic builtins, but if it does,
something like this might help since it's the u64 case that's
problematic.
I probably noviced this in some trivial way, but it's a thought.
And in the most-annoying case (most of these u64 divisions are power of
2, that I've seen...) would sort things out.
regards, Kyle
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d3cd23f..4936eb6 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -51,6 +51,9 @@ extern const char linux_proc_banner[];
#define DIV_ROUND_CLOSEST(x, divisor)( \
{ \
typeof(divisor) __divisor = divisor; \
+ if (__builtin_types_compatible_p(typeof(divisor), unsigned long long) && \
+ __builtin_popcountll(__divisor) == 1) \
+ (((x) + ((__divisor) / 2) << __builtin_ffsll(__divisor))); \
(((x) + ((__divisor) / 2)) / (__divisor)); \
} \
)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
