From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424085AbcFHJcu (ORCPT ); Wed, 8 Jun 2016 05:32:50 -0400 Received: from terminus.zytor.com ([198.137.202.10]:55572 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423817AbcFHJcq (ORCPT ); Wed, 8 Jun 2016 05:32:46 -0400 Subject: Re: [PATCH 02/10] x86, asm: use bool for bitops and other assembly outputs To: Ingo Molnar References: <1465342269-492350-1-git-send-email-hpa@linux.intel.com> <1465342269-492350-3-git-send-email-hpa@linux.intel.com> <20160608074956.GO30154@twins.programming.kicks-ass.net> <20160608082835.GB9645@gmail.com> <20160608083340.GC9645@gmail.com> <02ee64ce-257a-ba93-1f49-6877f5e4f6db@zytor.com> <20160608090111.GA11390@gmail.com> <88387994-fbf1-83dd-d58d-343498776a11@zytor.com> <20160608092040.GA17389@gmail.com> Cc: Peter Zijlstra , "H. Peter Anvin" , Thomas Gleixner , Linux Kernel Mailing List , Andy Lutomirski , Borislav Petkov , Linus Torvalds , Arnd Bergmann From: "H. Peter Anvin" Message-ID: <9ce48c59-4b9c-bd48-ce07-b230376fba0f@zytor.com> Date: Wed, 8 Jun 2016 02:31:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160608092040.GA17389@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/08/16 02:20, Ingo Molnar wrote: > > Yeah, absolutely. I hate 'bool' with a vengence but if 'int' generates worse code > with modern compilers then I'm not going to argue for worse code. Would a 'char' > return type be very weird? > Yes. I have to admit I don't share your hatred for "bool" -- it gives the compiler a fairly crucial bit of information about what the possible values are for a certain piece of data. Upcasting to char loses that, and may case gcc to manifest the value as an integer instead of retaining it in the flags. It is, however, less likely to cause gcc to then try to widen the value to word size (which is an extra instruction on x86), but moving the value out of and back into the flags register is the big cost. -hpa