Message-ID: <57D54DC5.4090800@emindsoft.com.cn>
Date:   Sun, 11 Sep 2016 20:27:49 +0800
From:   Chen Gang <chengang@...ndsoft.com.cn>
To:     Al Viro <viro@...IV.linux.org.uk>
CC:     Vineet Gupta <Vineet.Gupta1@...opsys.com>,
        Arnd Bergmann <arnd@...db.de>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "gi-oh.kim@...fitbricks.com" <gi-oh.kim@...fitbricks.com>,
        "iamjoonsoo.kim@....com" <iamjoonsoo.kim@....com>,
        "hillf.zj@...baba-inc.com" <hillf.zj@...baba-inc.com>,
        "mgorman@...hsingularity.net" <mgorman@...hsingularity.net>,
        "mhocko@...e.com" <mhocko@...e.com>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "rth@...ddle.net" <rth@...ddle.net>,
        "ink@...assic.park.msu.ru" <ink@...assic.park.msu.ru>,
        "mattst88@...il.com" <mattst88@...il.com>,
        "linux@...linux.org.uk" <linux@...linux.org.uk>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will.deacon@....com" <will.deacon@....com>,
        "hskinnemoen@...il.com" <hskinnemoen@...il.com>,
        "egtvedt@...fundet.no" <egtvedt@...fundet.no>,
        "realmz6@...il.com" <realmz6@...il.com>,
        "ysato@...rs.sourceforge.jp" <ysato@...rs.sourceforge.jp>,
        "rkuo@...eaurora.org" <rkuo@...eaurora.org>,
        "tony.luck@...el.com" <tony.luck@...el.com>,
        "fenghua.yu@...el.com" <fenghua.yu@...el.com>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "james.hogan@...tec.com" <james.hogan@...tec.com>,
        "ralf@...ux-mips.org" <ralf@...ux-mips.org>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "deller@....de" <deller@....de>,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>,
        "paulus@...ba.org" <paulus@...ba.org>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "schwidefsky@...ibm.com" <schwidefsky@...ibm.com>,
        "heiko.carstens@...ibm.com" <heiko.carstens@...ibm.com>,
        "dalias@...c.org" <dalias@...c.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: cmsg newgroup alt.sex.fetish.bool (was Re: [PATCH] arch: all:
 include: asm: bitops: Use bool instead of int for all bit test functions)



On 9/4/16 09:01, Al Viro wrote:
> On Sun, Sep 04, 2016 at 06:36:56AM +0800, Chen Gang wrote:
> 
>> And for all: shall I provide the proof for another archs?
>>
>> For me, Boolean gives additional chance to compiler to improve the code.
> 
> Whereas for compiler it gives nothing.  Not in those cases.
> 
>> If the compiler can not improve the code, it can treat it as int simply.
>> So theoretically, at least, Boolean should not be worse than int.
> 
> Except for pointless code churn and pandering to irrational beliefs, that is...

For me, it is not quite suitable to get conclusion during discussing.

> Please, RTFISO9899 and learn the semantics of _Bool; it's not that complicated.
> Start with 6.2.5[2,6] and 6.3.1.2, then look through 6.8.4 and 6.8.5 to
> figure out the semantics of conditions in if/while/for.  Note also 6.5.8,
> 6.5.9, 6.5.13 and 6.5.14 and observe that type of (x > 5 && y < 1) is *NOT* 
> _Bool; it's int.
>

Yes, what you said above is true to me. But for (x > 5 && y < 1) will
return 1 for true and 0 for false, although its' type is still int. So
for compiler, it can simply treat it as Boolean type internally.

For my original saying, I assume 2 things (excuse me, I did not mention
originally):

 - I assume what I said is for pure Boolean functions, in our case, all
   functions intend to return 'Boolean' value (0 or 1) in most of archs,
   although they use int type as return value.

 - What I said is for compiler's optimization at middle language level
   and at instruction level (internal processing), not for language
   definition (interface for outside -- for C developers).

For me, one way is: in middle language level, bool can be treated as int
or long to be processed firstly, then in instruction level, the compiler
performs additional optimization and qualification for bool.

 - So the compiler has additional chance for optimizing in instruction
   level.

 - Since for pure Boolean function, it is already sure that related int
   value must be 0 or 1, and the compiler should be smart enough to know
   that, so the output code need not additional qualifications.

 - So, for me, theoretically, bool is equal or better than int for pure
   bool functions, unless the compiler has performance bugs.

> If you can show any improvement or loss in code generation in this case
> (static inline int converted to static inline bool), I would really like to
> see the details.  As in .config/file/function/gcc version/target architecture.
> Optimizer bugs happens, but they should be reported when found, and I would
> expect _Bool handling to be _less_ exercised than that of normal logical
> expressions, so loss is probably more likely.  And yes, it also should be
> reported.
> 

At least for x86_64 arch, as far as I know, I can find the case which
bool is better than int, but I can not find the case which worse than
int.

Thanks.
-- 
Chen Gang (陈刚)

Managing Natural Environments is the Duty of Human Beings.

Powered by blists - more mailing lists