From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756031AbcIKM0j (ORCPT ); Sun, 11 Sep 2016 08:26:39 -0400 Received: from out1134-209.mail.aliyun.com ([42.120.134.209]:2688 "EHLO out1134-209.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755728AbcIKM0g (ORCPT ); Sun, 11 Sep 2016 08:26:36 -0400 X-Greylist: delayed 319 seconds by postgrey-1.27 at vger.kernel.org; Sun, 11 Sep 2016 08:26:36 EDT X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07487897|-1;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03292;MF=chengang@emindsoft.com.cn;NM=1;PH=DS;RN=38;RT=38;SR=0;TI=SMTPD_----5GTesyC_1473596426; Message-ID: <57D54DC5.4090800@emindsoft.com.cn> Date: Sun, 11 Sep 2016 20:27:49 +0800 From: Chen Gang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Al Viro CC: Vineet Gupta , Arnd Bergmann , "akpm@linux-foundation.org" , "minchan@kernel.org" , "vbabka@suse.cz" , "gi-oh.kim@profitbricks.com" , "iamjoonsoo.kim@lge.com" , "hillf.zj@alibaba-inc.com" , "mgorman@techsingularity.net" , "mhocko@suse.com" , "rientjes@google.com" , "linux-kernel@vger.kernel.org" , "rth@twiddle.net" , "ink@jurassic.park.msu.ru" , "mattst88@gmail.com" , "linux@armlinux.org.uk" , "catalin.marinas@arm.com" , "will.deacon@arm.com" , "hskinnemoen@gmail.com" , "egtvedt@samfundet.no" , "realmz6@gmail.com" , "ysato@users.sourceforge.jp" , "rkuo@codeaurora.org" , "tony.luck@intel.com" , "fenghua.yu@intel.com" , "geert@linux-m68k.org" , "james.hogan@imgtec.com" , "ralf@linux-mips.org" , "dhowells@redhat.com" , "deller@gmx.de" , "benh@kernel.crashing.org" , "paulus@samba.org" , "mpe@ellerman.id.au" , "schwidefsky@de.ibm.com" , "heiko.carstens@de.ibm.com" , "dalias@libc.org" , "David S. Miller" 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) References: <1472362755-26776-1-git-send-email-chengang@emindsoft.com.cn> <201608291503.41630.arnd@arndb.de> <80e3ae6c-e81d-3541-9051-07ad726b59cd@synopsys.com> <57C4ADD1.6020609@emindsoft.com.cn> <20160901204348.GQ2356@ZenIV.linux.org.uk> <57CA0C5D.1080701@emindsoft.com.cn> <8f1f06e3-0ca1-dfec-3ccf-ca155c61fdc6@synopsys.com> <57CB5088.6050007@emindsoft.com.cn> <20160904010144.GD2356@ZenIV.linux.org.uk> In-Reply-To: <20160904010144.GD2356@ZenIV.linux.org.uk> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.