From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-79672-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 82146 invoked by alias); 23 May 2017 20:57:20 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 82134 invoked by uid 89); 23 May 2017 20:57:20 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=
X-HELO: mail-oi0-f47.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:in-reply-to:references:from:date
         :message-id:subject:to:cc;
        bh=ZV1+ZfTmn4mWZ4k0At6kB9mX+Dv714jaf9lYmw6dZ3I=;
        b=rBNFQ7NIJqHp4h3F3MiqPTtB0JhwR41u2QupurL2j9mZblhgVra/GwseONZeWj9nmN
         IvcZcavdRGIIqR1+dnRmL/V6Dopzi4fDW64mM6mFvJCO6lUWPc9+VY7Rg3Z8rTobwIF5
         AQTSZbkTDlhz7qu15rTNLAG5IwZ0Kbzz7aTz6uHzzO3kIxidQzHS/GdSl/fiIdag0o2G
         PU5syVRrvHndj5CbwwxMxQ+h0mzWmQwhELekk10G2NrU4633YIJy5lCMmOgGVMLlB7x8
         XdXgQDMGK/Mvel/+zoApJjYurFUj2B9YMJwU4u8MZnQFTAcm5PH131O9kyyoeXIvtclZ
         EjEw==
X-Gm-Message-State: AODbwcBDNECePP//cdnmC+AinbtsugQpgJ8LZMK8BrTeHy1ZusXjF4sG
	2n+UghWHJHuY1bRrNfm1qH4jRvlvvIA1
X-Received: by 10.157.60.176 with SMTP id z45mr2548204otc.253.1495573040288;
 Tue, 23 May 2017 13:57:20 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <CAMe9rOojPP-Uk3Mqk41ReF4S-Q3MJ7XfvC9fHt5L2M4wG5KCYw@mail.gmail.com>
References: <CAOVZoAPo-A5-bRZFHeu_wvTASzh_4nYwmqfCVfHQ7h34GyWKAA@mail.gmail.com>
 <9c563a4b-424b-242f-b82f-4650ab2637f7@redhat.com> <CAOVZoAO9Ryz0uqGx4aXi+vf27c_+j8e+_opxcfQK27qO0OnBpw@mail.gmail.com>
 <CAMe9rOo8SbuodNhZugDLhdRPU=8OZuKVp4eT+3-6Gw-K0OLs3Q@mail.gmail.com>
 <CAOVZoAMmOoPU2ECGGiM6=tXdNXmd6HhKEqu67dP3u_WZ5gfm3Q@mail.gmail.com>
 <CAMe9rOr-E6OsDYsUCc7ci54e9R7A+BjH82eiMvLydtiJD61uzw@mail.gmail.com>
 <28e34264-e8c5-5570-c48c-9125893808b2@redhat.com> <CAOVZoAPp3_T+ourRkNFXHfCSQUOMFn4iBBm9j50==h=VJcGSzw@mail.gmail.com>
 <CAMe9rOpi75y5ATt8bUYSB6LJexQNfOXbOb=gYdMG3d3g4P6U9Q@mail.gmail.com>
 <CAMe9rOrznBXKWHL5bOUSs75A96j_5jiHF+W+D-U3tusYpbwp0Q@mail.gmail.com>
 <CAOVZoANj7Oqu66oXcfn-Fmi5UHVaxBRd-bkxVbaSr3bWUPXaXg@mail.gmail.com>
 <CAMe9rOpO_q8hMt+U4xUB8HoR9i7E0LO92SCiU_=v_306XdtjJQ@mail.gmail.com>
 <CAOVZoAOWzf0U7T-1Gbf7YUOfz4+X4frE+y1OHbSuQ-_Ta1uX2w@mail.gmail.com>
 <CAMe9rOowieroCST=wq81Co+OHud81jyjJZ8OZpqQCmEnnoPZfQ@mail.gmail.com>
 <CAOVZoAM8iAhH__mtm+HUZb8N6OXk1P=9QKgFeewtmStmXzVSMg@mail.gmail.com>
 <CAOVZoAPF1me2Dob43f7V_y5ENAGaivOJZCS0h9G6ntL9+JRMDg@mail.gmail.com> <CAMe9rOojPP-Uk3Mqk41ReF4S-Q3MJ7XfvC9fHt5L2M4wG5KCYw@mail.gmail.com>
From: Erich Elsen <eriche@google.com>
Date: Tue, 23 May 2017 20:57:00 -0000
Message-ID: <CAOVZoAO=4dD1DJtMzh=kwxAi5urt0Z_oGm=kQh3pegBxAkquHg@mail.gmail.com>
Subject: Re: memcpy performance regressions 2.19 -> 2.24(5)
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: "Carlos O'Donell" <carlos@redhat.com>, GNU C Library <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-SW-Source: 2017-05/txt/msg00700.txt.bz2

Maybe there's room for both?

Setting the cpu_features would affect everything; it would be useful
to be able to target only specific (and very important) routines.

On Tue, May 23, 2017 at 1:46 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, May 23, 2017 at 1:39 PM, Erich Elsen <eriche@google.com> wrote:
>> I was also thinking that it might be nice to have a TUNABLE that sets
>> the implementation of memcpy directly.  It would be easier to do this
>> if memcpy.S was memcpy.c.  Attached is a patch that does the
>> conversion but doesn't add the tunables.  How would you feel about
>> this?  It has no runtime impact, probably increases the size slightly,
>> and makes the code easier to read / modify.
>>
>
> It depends on how far you want to go.  We can add TUNABLE support
> to each IFUNC implementation or we can add TUNABLE support to
> cpu_features to update processor features.  I prefer latter.
>
>
> --
> H.J.