public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Pinski <pinskia@gmail.com>
To: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
	"Ellcey, Steve" <Steve.Ellcey@cavium.com>,
	 libc-alpha <libc-alpha@sourceware.org>,
	Wilco Dijkstra <Wilco.Dijkstra@arm.com>, nd <nd@arm.com>
Subject: Re: Ping: [Patch] aarch64: Thunderx specific memcpy and memmove
Date: Thu, 25 May 2017 16:28:00 -0000	[thread overview]
Message-ID: <CA+=Sn1nwmW++JVH+ibFpC=80pByaSGWnB6MNGY0vsU8T5vV=-g@mail.gmail.com> (raw)
In-Reply-To: <0950612b-cff4-2256-6f81-3bacf30ce7e9@gotplt.org>

On Wed, May 24, 2017 at 11:42 PM, Siddhesh Poyarekar
<siddhesh@gotplt.org> wrote:
> On Wednesday 24 May 2017 10:34 PM, Szabolcs Nagy wrote:
>> - i don't know if you plan to make more changes to the thunderx
>> memcpy, if prefetching is the only change then it's likely that
>> we can agree on a generic version that's good enough.  if you
>> do plan to make further changes, then keep in mind that we try
>> to have same/similar generic memcpy across c runtimes and if
>> your change is good for generic we might not be able to use the
>> code outside of glibc (so newlib, bionic, freebsd,.. memcpy
>> would diverge)
>
> Steve, if that is desirable then please consider contributing the code
> to cortex-strings[1].

One memcpy does not fit all micro-arch.  Just look at x86, where they
have many different versions and even do selection based on cache size
(see the current discussion about the memcpy regression).

>
>> - non-thunderx systems are affected: static linked code using
>> memcpy will start to go through an indirection (iplt) instead
>> of direct call. if there are complaints about it or other ifunc
>> related issues come up, then again we will have to reconsider it.

Just to answer this.  This is true on x86 and PowerPC already so there
should be no difference on aarch64 than those two targets.

>
> They could use a library built with --disable-multiarch.  The only place
> I can see this happening is on systems that currently need bespoke
> images, e.g. raspberry pis or similar form factors.  Since they're
> building custom images anyway, it shouldn't be too hard to add a glibc
> built with --disable-multiarch for them.
>
> Removing multiarch completely is not an option since there's thunderx
> *and* falkor (yes yes, coming soon, I promise!) with their own routines
> and perhaps more in future.

ThunderX2T99 version should be posted by the end of next week.

>
> Siddhesh
>
> [1] https://launchpad.net/cortex-strings

  reply	other threads:[~2017-05-25 16:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-01 18:27 Steve Ellcey
2017-05-01 21:20 ` Wainer dos Santos Moschetta
2017-05-03 14:01 ` Szabolcs Nagy
2017-05-09  3:17   ` Siddhesh Poyarekar
2017-05-09 21:45     ` Steve Ellcey
2017-05-18 21:48       ` Steve Ellcey
2017-05-19  7:41       ` Siddhesh Poyarekar
     [not found]         ` <DM5PR07MB34662F805C1EDE45882B82F6F5F90@DM5PR07MB3466.namprd07.prod.outlook.com>
2017-05-24 17:04           ` Szabolcs Nagy
2017-05-25  6:42             ` Siddhesh Poyarekar
2017-05-25 16:28               ` Andrew Pinski [this message]
2017-05-25 16:43                 ` Ramana Radhakrishnan
2017-05-25 17:49                 ` Wilco Dijkstra
2017-05-25 19:26                   ` Siddhesh Poyarekar
2017-05-25 21:04                     ` Ramana Radhakrishnan
2017-05-25 21:12                       ` Florian Weimer
2017-05-26  5:42                         ` Siddhesh Poyarekar
2017-05-26  5:34                       ` Siddhesh Poyarekar
2017-05-26  5:38                         ` Andrew Pinski
2017-05-25 16:22             ` Steve Ellcey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+=Sn1nwmW++JVH+ibFpC=80pByaSGWnB6MNGY0vsU8T5vV=-g@mail.gmail.com' \
    --to=pinskia@gmail.com \
    --cc=Steve.Ellcey@cavium.com \
    --cc=Wilco.Dijkstra@arm.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    --cc=siddhesh@gotplt.org \
    --cc=szabolcs.nagy@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).