From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13935 invoked by alias); 12 Dec 2012 18:37:55 -0000 Received: (qmail 13745 invoked by uid 22791); 12 Dec 2012 18:37:52 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W X-Spam-Check-By: sourceware.org Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Dec 2012 18:37:48 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 12 Dec 2012 10:36:47 -0800 X-ExtLoop1: 1 Received: from tassilo.jf.intel.com ([10.7.201.84]) by orsmga002.jf.intel.com with ESMTP; 12 Dec 2012 10:37:36 -0800 Received: by tassilo.jf.intel.com (Postfix, from userid 501) id 5C2692438FD; Wed, 12 Dec 2012 10:37:36 -0800 (PST) From: Andi Kleen To: Jan Hubicka Cc: Xinliang David Li , GCC Patches , Teresa Johnson Subject: Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs References: <20121212163722.GA21037@atrey.karlin.mff.cuni.cz> <20121212183036.GB5303@atrey.karlin.mff.cuni.cz> Date: Wed, 12 Dec 2012 18:37:00 -0000 In-Reply-To: <20121212183036.GB5303@atrey.karlin.mff.cuni.cz> (Jan Hubicka's message of "Wed, 12 Dec 2012 19:30:36 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-12/txt/msg00843.txt.bz2 Jan Hubicka writes: > > libcall is not faster up to 8KB to rep sequence that is better for regalloc/code > cache than fully blowin function call. I noticed btw that some of the generated string instructions are slower than just calling the C library. rep scasb etc. is rarely a win over an optimized library function, it's not very optimized. Perhaps those patterns should just be disabled. The way to optimize that on modern CPUs is to use PCMP*STR*, but that's quite a bit more complicated and has some constraints. >> > /* X86_TUNE_FOUR_JUMP_LIMIT: Some CPU cores are not able to predict more >> > than 4 branch instructions in the 16 byte window. */ >> > - m_PPRO | m_P4_NOCONA | m_CORE2I7 | m_ATOM | m_AMD_MULTIPLE | m_GENERIC, >> > + m_PPRO | m_P4_NOCONA | m_ATOM | m_AMD_MULTIPLE | m_GENERIC, > > This is special passs to handle limitations of AMD's K7/K8/K10 branch prediction. > Intel never had similar design, so this flag is pointless. Actually the Sandy Bridge decoded icache has a limit of 3 jumps per 16 byte window. If you exceed that it falls back to running the full decoder from the normal icache. I don't have solid data, but it may be a win for frontend limited code (otherwise possibly more in power than performance) I would revisit that for Sandy Bridge -Andi -- ak@linux.intel.com -- Speaking for myself only