From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 90068d19 for ; Wed, 15 Jan 2020 20:54:28 +0000 (UTC) Received: (qmail 27765 invoked by uid 550); 15 Jan 2020 20:54:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27745 invoked from network); 15 Jan 2020 20:54:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=+75mBR87/zNrB7Lt6Fhq4CuRRoBBzr24SWgxAafMct8=; b=Q/UqoJbxMymWLRjYNgBPBYneRQNYeNjBh2+LOKGrhISxHQLUNT1lOGVEpKbh1u9OPD QDl66/f/LTB94kjw8acRFHx9imohLYlZOMGPmxwgTRq/QoCnBoRbzCJJnql5MvyLDgBj /ARpMPbysXtN2EJUZRfLOMNMYqcJtVHORoRZ6r9Q+JfesyEpSd0Oa1WyxsJ2/ht+f5TJ YUda58GJKQrTzAOVd8WGFua6GCeN2zyX/EdYRVWbjO2Ywk+969r3EHOxsYGJ1aeiziD7 unoofkI/KyS+Dd+JH9PtV5QCeUdt2q9xvuK3/xSaFlgewhMiUucBygIN93iAGBYPSlGL DpdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+75mBR87/zNrB7Lt6Fhq4CuRRoBBzr24SWgxAafMct8=; b=hmjO1Oi8mmrXrSo5nf43A8l4YoNQtnnfCC3L5K0eXJA1Kmd+mTsUHmQ5VCrhnLESe6 y5+yY1uXb3Ed2UhhCzWIL9giYwCwRpDpCBXjtANWL2dqkSwYzWcUO6T+rseeNLcVvu54 tpFOvOGKit5n9s5TeXPmBhB2pxI1bSXP9CaTPMaOoK9Ue+0YC6SH0nlHRwq09iCSQSnb DG6SSk1NhG2hkn/kXImJdcxZKy6vBkPFA8DoKNKpIyoXnD4elWjlSbkSiQ4W/VX2Mn9/ LF4D3KT2c1mB2MF1+zDyt5czAg7fEuCYBS/5kBNIcko4oGBF/WDGOmZ6z5NBr4eIwFYo FSpw== X-Gm-Message-State: APjAAAVgAvQ2R/VBJkfFBi7rMWhIasqtXWEeIIDYYqIooKBa6YbXB89n +sfVihzq+K3p3rm98LzrfNjQO9loK/cyiAxU5/dmnQ== X-Google-Smtp-Source: APXvYqxY/bATfOLCasVFtkz94lzI5L8EoBu3DjmJN44GUzjAfsApaHpBOuhkxlkj9Mltghb0ubXMRl17oLg6b5nwfGU= X-Received: by 2002:a67:e443:: with SMTP id n3mr5840528vsm.137.1579121654683; Wed, 15 Jan 2020 12:54:14 -0800 (PST) MIME-Version: 1.0 References: <20190913184432.29753-1-armccurdy@gmail.com> <20190913184432.29753-2-armccurdy@gmail.com> <20190913185910.GK9017@brightrain.aerifal.cx> <20200115154553.GH30412@brightrain.aerifal.cx> <20200115192215.GJ30412@brightrain.aerifal.cx> In-Reply-To: <20200115192215.GJ30412@brightrain.aerifal.cx> From: Andre McCurdy Date: Wed, 15 Jan 2020 12:54:03 -0800 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] [PATCH 2/2] Add big-endian support to ARM assembler memcpy On Wed, Jan 15, 2020 at 11:22 AM Rich Felker wrote: > On Wed, Jan 15, 2020 at 10:41:08AM -0800, Andre McCurdy wrote: > > On Wed, Jan 15, 2020 at 7:46 AM Rich Felker wrote: > > > On Fri, Sep 13, 2019 at 01:38:34PM -0700, Andre McCurdy wrote: > > > > On Fri, Sep 13, 2019 at 11:59 AM Rich Felker wrote: > > > > > On Fri, Sep 13, 2019 at 11:44:32AM -0700, Andre McCurdy wrote: > > > > > > Allow the existing ARM assembler memcpy implementation to be used for > > > > > > both big and little endian targets. > > > > > > > > > > Nice. I don't want to merge this just before release, but as long as > > > > > it looks ok I should be able to review and merge it afterward. > > > > > > > > > > Note that I'd really like to replace this giant file with C using > > > > > inline asm just for the inner block copies and C for all the flow > > > > > control, but I don't mind merging this first as long as it's correct. > > > > > > > > Sounds good. I'll wait for your feedback after the upcoming release. > > > > > > Sorry this dropped off my radar. I'd like to merge at least the thumb > > > part since it's simple enough to review quickly and users have > > > actually complained about memcpy being slow on armv7 with -mthumb as > > > default. > > > > Interesting. I wonder what the reference was against which the musl C > > code was compared? From my own benchmarking I didn't find the musl > > assembler to be much faster than the C code. There are armv6 and maybe > > early armv7 CPUs where explicit prefetch instructions make a huge > > difference (much more so than C -vs- assembler). Did the users who > > complained about musl memcpy() compare against a memcpy() which uses > > prefetch? For armv7 using NEON may help, although the latest armv7 > > cores seem to perform very well with plain old C code too. There are > > lots of trade offs so it's impossible for a single implementation to > > be universally optimal. The "arm-mem" routines used on Raspberry Pi > > seem to be a very fast for many targets, but unfortunately the armv6 > > memcpy generates mis-aligned accesses so isn't suitable for armv5. > > > > https://github.com/bavison/arm-mem/ > > I'm not sure of the details but the comparison was just between the > armv6 version of Alpine and the armv7 version (so using musl's > memcpy_le.S vs memcpy.c). OK. A comparison with the arm-mem version would be interesting too. The arm-mem library is designed to be preloaded (ahead of glibc for Raspberry Pi distros) so it should be possible to preload ahead of musl on Alpine, which makes testing slightly easier.