From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56940 invoked by alias); 11 Aug 2017 11:22:50 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 56812 invoked by uid 89); 11 Aug 2017 11:22:49 -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,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=oppose X-HELO: homiemail-a119.g.dreamhost.com Subject: Re: [PATCH 0/2] Multiarch hooks for memcpy variants To: Wilco Dijkstra , "libc-alpha@sourceware.org" Cc: nd References: From: Siddhesh Poyarekar Message-ID: <18d2fdf8-ca55-1ded-fa66-3509b3bcf8fe@gotplt.org> Date: Fri, 11 Aug 2017 11:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-08/txt/msg00424.txt.bz2 On Friday 11 August 2017 04:41 PM, Wilco Dijkstra wrote: > Siddhesh Poyarekar wrote: >> Functions like mempcpy, __mempcpy_chk and __memcpy_chk continue to call the >> generic memcpy implementation. These two patches fix this by adding ifunc >> entry points for these functions for generic, thunderx and falkor. > > I don't understand what the goal of this is since on AArch64 we always transform > mempcpy to memcpy. Also why use ifuncs on the _chk variants? Are they ever > used in cases where the last 1% of performance matters? I started off by writing this for __memcpy_chk because gcc transforms memcpy to __memcpy_chk in some cases with -O3 and then extended it to mempcpy for completeness. I'm not going to push too hard for mempcpy if you strongly oppose it, but I am definitely interested in getting __memcpy_chk ifuncs in. Siddhesh