From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757293AbbEEJlF (ORCPT ); Tue, 5 May 2015 05:41:05 -0400 Received: from torres.puc.rediris.es ([130.206.18.9]:56506 "EHLO torres.puc.rediris.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161183AbbEEJky (ORCPT ); Tue, 5 May 2015 05:40:54 -0400 X-Greylist: delayed 2278 seconds by postgrey-1.27 at vger.kernel.org; Tue, 05 May 2015 05:40:54 EDT X-Envelope-From: paubert@iram.es Date: Tue, 5 May 2015 11:01:05 +0200 From: Gabriel Paubert To: Richard Henderson Cc: Peter Zijlstra , Linus Torvalds , Vladimir Makarov , Jakub Jelinek , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , Linux Kernel Mailing List , Borislav Petkov , "gcc@gcc.gnu.org" Subject: Re: [RFC] Design for flag bit outputs from asms Message-ID: <20150505090105.GA18697@visitor2.iram.es> References: <20150501151630.GH5029@twins.programming.kicks-ass.net> <20150501163329.GU1751@tucnak.redhat.com> <5543CDC0.6010206@redhat.com> <20150502123958.GK5029@twins.programming.kicks-ass.net> <5547C992.9000703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5547C992.9000703@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: power7.md] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4974] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote: [snipped] > (3) Note that ppc is both easier and more complicated. > > There we have 8 4-bit registers, although most of the integer > non-comparisons only write to CR0. And the vector non-comparisons > only write to CR1, though of course that's of less interest in the > context of kernel code. Actually vector (Altivec) write to CR6. Standard FPU optionally write to CR1, but the written value does not exactly depend on the result of the last instruction; it is an instead an accrued exception status. > > For the purposes of cr0, the same scheme could certainly work, although > the hook would not insert a hard register use, but rather a pseudo to > be allocated to cr0 (constaint "x"). Yes, but we might also want to leave the choice of a cr register to the compiler. > > That said, it's my understanding that "dot insns", setting cr0 are > expensive in current processor generations. Not that much if I understand properly power7.md and power8.md: no (P7) or one (P8) additional clock for common instructions (add/sub and logical), but nothing else, so they are likely a win. Shift/rotate/sign extensions seem to have more decoding restrictions: the recording ("dot") forms are "cracked" and use 2 integer units. > There's also a lot less > of the x86-style "operate and set a flag based on something useful". > But there is at least an important one, which I occasionally wished I had: the conditional stores. The overflow bit might also be useful, not really for the kernel, but for applications (and mfxer is slow). Regards, Gabriel