Movatterモバイル変換

This is the mail archive of thelibc-alpha@sourceware.orgmailing list for theglibc project.

Re: [PATCH 0/2] Multiarch hooks for memcpy variants

• From: Siddhesh Poyarekar <siddhesh at gotplt dot org>
• To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
• Cc: nd <nd at arm dot com>
• Date: Fri, 11 Aug 2017 16:52:41 +0530
• Subject: Re: [PATCH 0/2] Multiarch hooks for memcpy variants
• Authentication-results: sourceware.org; auth=none
• References: <DB6PR0801MB20534ED1010DDF1B033821EE83890@DB6PR0801MB2053.eurprd08.prod.outlook.com>

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 transformsmemcpy to __memcpy_chk in some cases with -O3 and then extended it tomempcpy for completeness.  I'm not going to push too hard for mempcpy ifyou strongly oppose it, but I am definitely interested in getting__memcpy_chk ifuncs in.Siddhesh

• Follow-Ups:
  • Re: [PATCH 0/2] Multiarch hooks for memcpy variants
    • From: Szabolcs Nagy

• References:
  • Re: [PATCH 0/2] Multiarch hooks for memcpy variants
    • From: Wilco Dijkstra