Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 28 Aug 2021 16:27:49 -0400
From: Jeffrey Walton <>
Subject: Re: Why the musl libc did not support neon simd acceleartor
 officially on mem* operations?

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.

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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.