From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-334202-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 27743 invoked by alias); 13 Dec 2012 20:40:57 -0000
Received: (qmail 27726 invoked by uid 22791); 13 Dec 2012 20:40:56 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0	tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,TW_CP
X-Spam-Check-By: sourceware.org
Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Dec 2012 20:40:51 +0000
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)	id 0E7A25428A3; Thu, 13 Dec 2012 21:40:49 +0100 (CET)
Date: Thu, 13 Dec 2012 20:40:00 -0000
From: Jan Hubicka <hubicka@ucw.cz>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Jan Hubicka <hubicka@ucw.cz>, Jakub Jelinek <jakub@redhat.com>,	Xinliang David Li <davidxl@google.com>,	GCC Patches <gcc-patches@gcc.gnu.org>,	Teresa Johnson <tejohnson@google.com>
Subject: Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs
Message-ID: <20121213204049.GE26009@kam.mff.cuni.cz>
References: <20121212163722.GA21037@atrey.karlin.mff.cuni.cz> <CAAkRFZKBa3GtEh=mmWiAmy-oGffYFxrmWetpaz+pKYSG1zSvSw@mail.gmail.com> <20121212183036.GB5303@atrey.karlin.mff.cuni.cz> <CAAkRFZLAe0CuO+-sBps9pCBDVi5k2ti8cBgL9Ukw4fBmrnpUeg@mail.gmail.com> <20121213011933.GB21037@atrey.karlin.mff.cuni.cz> <CAAkRFZ+gf-733+7djNrEyi6t_Sx6UzH3xSXsAGAMH+oWwCjN1Q@mail.gmail.com> <20121213062128.GK2315@tucnak.redhat.com> <CAMe9rOri3djrv29rQKMLS8jdYvJ8xxs+7xDaL6U-iKa=ojOjrw@mail.gmail.com> <20121213202601.GD26009@kam.mff.cuni.cz> <CAMe9rOr9m9hcVPEgU3vYn=QFX8=2fCjFg6LgtMohjfqSCpbTig@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMe9rOr9m9hcVPEgU3vYn=QFX8=2fCjFg6LgtMohjfqSCpbTig@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2012-12/txt/msg00944.txt.bz2

> > Here we speak about memcpy/memset only.  I never got around to modernize
> > strlen and friends, unfortunately...
> >
> > memcmp and friends are different beats.  They realy need some TLC...
> 
> memcpy and memset in glibc are also extremely fast.

The default strategy now is to inline only when the block is known to be small
(either constant or via profile feedback, we do not really use the info on
upper bound of size of the copied object that would be useful but not readilly
available at expansion time).

You can try the test_stringop script I attached and send me the results.  For
me libc starts to be win only for rather large blocks (i.e. >8KB)

Honza