[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4AC2943E.2070502@cesarb.net>
Date: Tue, 29 Sep 2009 20:11:58 -0300
From: Cesar Eduardo Barros <cesarb@...arb.net>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: linux-kernel@...r.kernel.org, rolandd@...co.com, dwalker@...o99.com
Subject: Re: [PATCH] WARN_ONCE(): use bool for condition
Andrew Morton escreveu:
> On Sun, 27 Sep 2009 15:25:12 -0300
> Cesar Eduardo Barros <cesarb@...arb.net> wrote:
>
>> Use the type bool for __ret_warn_once and __ret_warn_on, instead of int
>> with a double negation. This matches the intent of the code better and
>> should allow the compiler to generate better code, like in commit
>> 70867453092297be9afb2249e712a1f960ec0a09. However, some versions of gcc
>> seems to pessimize the code instead when the condition is not trivial.
>
> There's a small reject in include/asm-generic/bug.h against current
> mainline, easily fixed.
>
> It would be nice if we had some accurate numbers on the kernel size
> reductions from this, please. I assume that the patch is still of
> benefit in 2.6.32-rc1(2?), but it's always good to confirm.
This one was the one where some compilers saw the size reduction and
other compilers saw the size _increase_ due to bad code generation.
The good one was the first post in the original thread, "[PATCH]
WARN_ONCE(): use bool for boolean flag" (the small reject you saw was
probably because that one was not applied before this one, since this
one was generated on top of that one).
In the first patch, Daniel Walker saw a decrease of 504 bytes in IA-32,
and I saw a decrease of 1462 bytes in x86-64 defconfig. I will resend it
as a reply to this email; I think it should be included, as there seems
to be no obvious drawbacks.
For this one, on the other hand, I am not sure whether it should be
included or dropped. While Daniel Walker saw a decrease of 84 bytes in
IA-32, I saw an *increase* of 598 bytes in x86-64 defconfig. It seems
the older compiler I am using (4.3.2-1ubuntu12) generates laughably bad
code for it (setting the variable just to test it again in the next
instruction).
Sorry for the confusion, I should have made more clear that both patches
were separate and meant to be applied in sequence (and that the second
one was under discussion).
--
Cesar Eduardo Barros
cesarb@...arb.net
cesar.barros@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists