From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98718 invoked by alias); 12 Apr 2018 15:17:35 -0000 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 Received: (qmail 98376 invoked by uid 89); 12 Apr 2018 15:17:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=HCC:D*gnu.org, HCC:D*gcc.gnu.org X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 12 Apr 2018 15:17:33 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2B612AD4B; Thu, 12 Apr 2018 15:17:31 +0000 (UTC) Date: Thu, 12 Apr 2018 15:17:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <20180412143112.GK8577@tucnak> References: <772b1171-2321-67d9-85e7-358a5cad0efa@suse.cz> <20180329122532.GP8577@tucnak> <17bbc039-e511-4fbe-d534-3d6d21aadc00@suse.cz> <2d812eaf-8ea0-68e8-089b-0c3d89a203d8@suse.cz> <20180410091915.GA8577@tucnak> <5b750aa0-c5f6-0e64-9a14-5667926bcf3f@suse.cz> <20180412140549.GJ8577@tucnak> <20180412143112.GK8577@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] Prefer mempcpy to memcpy on x86_64 target (PR middle-end/81657). To: Jakub Jelinek CC: =?UTF-8?Q?Martin_Li=C5=A1ka?= ,Uros Bizjak ,gcc-patches@gcc.gnu.org,Marc Glisse ,"H.J. Lu" ,Jan Hubicka From: Richard Biener Message-ID: X-SW-Source: 2018-04/txt/msg00613.txt.bz2 On April 12, 2018 4:31:12 PM GMT+02:00, Jakub Jelinek wr= ote: >On Thu, Apr 12, 2018 at 04:19:38PM +0200, Richard Biener wrote: >> Well, but that wouldn't be a fix for a regression and IMHO there's >> no reason for a really lame mempcpy. If targets disgree well, > >It is a regression as well, in the past we've emitted mempcpy when user >wrote mempcpy, now we don't. > >E.g. >extern void *mempcpy (void *, const void *, __SIZE_TYPE__); >void bar (void *, void *, void *); > >void >foo (void *x, void *y, void *z, void *w, __SIZE_TYPE__ n) >{ > bar (mempcpy (x, w, n), mempcpy (y, w, n), mempcpy (z, w, n)); >} > >is on x86_64-linux -O2 in 7.x using the 3 mempcpy calls and 90 bytes in >foo, while >on the trunk uses 3 memcpy calls and 96 bytes in foo. > >For -Os that is easily measurable regression, for -O2 it depends on the >relative speed of memcpy vs. mempcpy and whether one or both of them >are in >I-cache or not. Well, then simply unconditionally not generate a libcall from the move expa= nder?=20 > >> then they get what they deserve. >>=20 >> I don't see any aarch64 specific mempcpy in glibc btw so hopefully >> the default non-stupid one kicks in (it exactly looks like my C >> version) > > Jakub