mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: [musl] [PATCH] aarch64: add optimized memcpy, memmove and memset
Date: Wed, 25 Mar 2020 21:49:11 -0400	[thread overview]
Message-ID: <20200326014911.GA11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200325214544.GT14278@port70.net>

On Wed, Mar 25, 2020 at 10:45:45PM +0100, Szabolcs Nagy wrote:
> minimal edits to upstream version for easier updates
> and because this code was benchmarked across many cores.
> 
> gcc generates slow code for the current c implementations.
> 
> the integer memcpy was chosen instead of the simd one,
> this performs better on little cores, i think this is
> the more conservative choice for now.

I think this was discussed before on IRC, and I'm not particularly
opposed to these especially since aarch64 is one of the most important
archs these days. However I would really like to avoid adding more asm
source files with the function flow written in asm when the only thing
that really needs to benefit from asm is the inner loop body. I know
nothing has happened on this front since we last talked about it, so
it's very possible that the answer is just "we need something with
decent performance in the short term and nobody has cycles to spend on
doing it better right now and so we we should just use the asm
files"...

> note: there are upcoming security architectures which
> may mean updates to these functions (BTI - landing pads,
> PAUTH - return address signing, MTE - 16byte tag granule
> may affect optimized strcmp etc, not relevant yet), but
> runtime support for these will need other libc changes.

If these mattered they'd be another reason to prefer having the
function in C with minimal inline asm or just extensions for unaligned
loads/stores, but MTE is the only one of these that's interesting and
it doesn't conflict with any current code in musl at all (nothing does
unaligned overreads; they have to be assumed to be able to fault
anyway).

Rich

      reply	other threads:[~2020-03-26  1:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 21:45 Szabolcs Nagy
2020-03-26  1:49 ` Rich Felker [this message]

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=20200326014911.GA11469@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).