mailing list of musl libc
 help / color / mirror / Atom feed
From: Rich Felker <>
To: Jeffrey Walton <>
Subject: Re: [musl] Why the musl libc did not support neon simd acceleartor officially on mem* operations?
Date: Sat, 28 Aug 2021 16:34:31 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On Sat, Aug 28, 2021 at 04:27:49PM -0400, Jeffrey Walton wrote:
> On Sat, Aug 28, 2021 at 3:53 PM Rich Felker <> wrote:
> >
> > On Sat, Aug 28, 2021 at 04:01:40PM +0800, tugouxp wrote:
> > > HI guys:
> > >   I found that the current implmention of musl arm port memcpy.S and
> > > other mem*.S operations did not use arm neon instructions, this
> > > seems differenct with other counterparts like newlibc, glibc and
> > > bonic libc, which all impl. the neon version of mem* operations. so
> > > could you tell me why? is there and concern about on this in musl?
> > > if i want to imple my self imple. how to do this, is there any
> > > matual pathches to use?
> >
> > Generally we don't have any significant asm implementations that
> > depend on non-baseline extensions to the ISA. The same is true for x86
> > where no sse/avx is used.
> Out of curiosity, does anyone use Hardware Capabilities
> ( nowadays? Something like a
> /usr/lib/musl, /usr/lib/sse/musl, /usr/lib/avx/musl,
> /usr/lib/neon/musl, etc?
> The benefit to using it is no runtime switching. The switching occurs
> at load time, not runtime.

No, this is a really really bad way to do it. It's not compatible with
static linking and greatly increases startup overhead finding the
right libraries (leading to glibc recently redesigning how they do

> I know of a handful of libraries that could benefit from the speed up
> on a critical path with an arch specific implementation. But I think
> most libraries don't need it.

If you really need this, assuming your distro/package installation
system knows what specific ISA extensions you want it could just
install suitable alt packages, *or* install both and edit the
ld-musl-$(ARCH).path file (or do boot-time symlink or bind mount
stuff, etc.) to make the desired ones available.


  reply	other threads:[~2021-08-28 20:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-28  8:01 tugouxp
2021-08-28  9:48 ` Markus Wichmann
2021-08-28 14:29   ` [musl] " tugouxp
2021-08-28 19:53 ` Rich Felker
2021-08-28 20:27   ` Jeffrey Walton
2021-08-28 20:34     ` Rich Felker [this message]
2021-09-04 13:56       ` Ismael Luceno

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:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ \
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone