From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29885 invoked by alias); 12 Dec 2012 18:43:15 -0000 Received: (qmail 29876 invoked by uid 22791); 12 Dec 2012 18:43:13 -0000 X-SWARE-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.26.193) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Dec 2012 18:43:04 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 1E47D80F56; Wed, 12 Dec 2012 19:43:03 +0100 (CET) Date: Wed, 12 Dec 2012 18:43:00 -0000 From: Jan Hubicka To: Andi Kleen Cc: Jan Hubicka , Xinliang David Li , GCC Patches , Teresa Johnson Subject: Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs Message-ID: <20121212184302.GC5303@atrey.karlin.mff.cuni.cz> References: <20121212163722.GA21037@atrey.karlin.mff.cuni.cz> <20121212183036.GB5303@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes 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/msg00844.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. This is only about memset/memcpy expanding. The other sequences are quite lame indeed... > > > >> > /* 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 We are not particularly good on avoiding the branches - basically the code inserts alignment whenever it things the 4 consecutive branches fit in the window. I can make patch to change this to 3 and we can see if it helps at all. > > -Andi > -- > ak@linux.intel.com -- Speaking for myself only