From: Joseph Myers <joseph@codesourcery.com>
To: Noah Goldstein <goldstein.w.n@gmail.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse4_1, avx2, and evex
Date: Wed, 15 Sep 2021 00:00:55 +0000 [thread overview]
Message-ID: <alpine.DEB.2.22.394.2109142351240.1167011@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20210913230506.546749-1-goldstein.w.n@gmail.com>
bcmp is an obsolescent function that no modern programs should be using,
and it's not in the implementation namespace either so compilers shouldn't
translate memcmp calls to bcmp.
If you want to define memcmp ABI variants optimized for particular usages,
I suggest the following:
1. Add reserved-namespace names for such variants to the x86_64 psABI
document (working with the ABI mailing list). The 32-bit Arm RTABI
<https://github.com/ARM-software/abi-aa/blob/main/rtabi32/rtabi32.rst>
provides a precedent for defining such function variants in a psABI (it
includes various __aeabi_mem*, though no memcmp variants).
2. Add those names to glibc, as well as teaching compilers to generate
calls to them (with appropriate conditionals for whether the functions are
known to be available in the target libc; in GCC, that would be based on
GCC_GLIBC_VERSION_GTE_IFELSE configure tests for targets using glibc).
As a variant, you could define such names as architecture-independent GNU
extensions rather than in a psABI, especially if there's nothing
architecture-specific about the variants you think are useful (e.g. no use
for having changes to calling conventions / call-clobbered registers for
the variants). But what should not be done in any case is tying an
optimization to an obsolescent non-reserved name - any such optimized
variants should use only implementation-namespace names.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2021-09-15 0:01 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-13 23:05 [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse4_1, avx2, and evex Noah Goldstein via Libc-alpha
2021-09-13 23:05 ` [PATCH 2/5] x86_64: Add sse2 optimized bcmp implementation in memcmp.S Noah Goldstein via Libc-alpha
2021-09-13 23:05 ` [PATCH 3/5] x86_64: Add sse4_1 optimized bcmp implementation in memcmp-sse4.S Noah Goldstein via Libc-alpha
2021-09-13 23:05 ` [PATCH 4/5] x86_64: Add avx2 optimized bcmp implementation in bcmp-avx2.S Noah Goldstein via Libc-alpha
2021-09-13 23:05 ` [PATCH 5/5] x86_64: Add evex optimized bcmp implementation in bcmp-evex.S Noah Goldstein via Libc-alpha
2021-09-14 1:18 ` Carlos O'Donell via Libc-alpha
2021-09-14 2:05 ` Noah Goldstein via Libc-alpha
2021-09-14 2:35 ` Carlos O'Donell via Libc-alpha
2021-09-14 2:55 ` DJ Delorie via Libc-alpha
2021-09-14 3:24 ` Noah Goldstein via Libc-alpha
2021-09-14 3:40 ` Noah Goldstein via Libc-alpha
2021-09-14 4:21 ` DJ Delorie via Libc-alpha
2021-09-14 5:29 ` Noah Goldstein via Libc-alpha
2021-09-14 5:42 ` DJ Delorie via Libc-alpha
2021-09-14 5:55 ` Noah Goldstein via Libc-alpha
2021-09-13 23:22 ` [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse4_1, avx2, and evex Noah Goldstein via Libc-alpha
2021-09-14 6:30 ` [PATCH v2 " Noah Goldstein via Libc-alpha
2021-09-14 6:30 ` [PATCH v2 2/5] x86_64: Add sse2 optimized bcmp implementation in memcmp.S Noah Goldstein via Libc-alpha
2021-09-14 6:30 ` [PATCH v2 3/5] x86_64: Add sse4_1 optimized bcmp implementation in memcmp-sse4.S Noah Goldstein via Libc-alpha
2021-09-14 6:30 ` [PATCH v2 4/5] x86_64: Add avx2 optimized bcmp implementation in bcmp-avx2.S Noah Goldstein via Libc-alpha
2021-09-14 6:30 ` [PATCH v2 5/5] x86_64: Add evex optimized bcmp implementation in bcmp-evex.S Noah Goldstein via Libc-alpha
2021-09-14 14:40 ` [PATCH v2 1/5] x86_64: Add support for bcmp using sse2, sse4_1, avx2, and evex H.J. Lu via Libc-alpha
2021-09-14 19:23 ` Noah Goldstein via Libc-alpha
2021-09-14 20:30 ` Florian Weimer via Libc-alpha
2021-09-15 0:00 ` Joseph Myers [this message]
2021-09-15 13:37 ` [PATCH " Zack Weinberg via Libc-alpha
2021-09-15 14:01 ` Re: [PATCH 1/5] x86_64: Add support for bcmp using sse2, sse 4_1, " Florian Weimer via Libc-alpha
2021-09-15 18:06 ` Noah Goldstein via Libc-alpha
2021-09-15 18:30 ` Joseph Myers
2021-09-27 1:35 ` Noah Goldstein via Libc-alpha
2021-09-27 7:29 ` Florian Weimer via Libc-alpha
2021-09-27 16:49 ` Noah Goldstein via Libc-alpha
2021-09-27 16:54 ` Florian Weimer via Libc-alpha
2021-09-27 17:54 ` Noah Goldstein via Libc-alpha
2021-09-27 17:56 ` Florian Weimer via Libc-alpha
2021-09-27 18:05 ` Noah Goldstein via Libc-alpha
2021-09-27 18:10 ` Florian Weimer via Libc-alpha
2021-09-27 18:15 ` Noah Goldstein via Libc-alpha
2021-09-27 18:22 ` Florian Weimer via Libc-alpha
2021-09-27 18:34 ` Noah Goldstein via Libc-alpha
2021-09-27 18:56 ` Florian Weimer via Libc-alpha
2021-09-27 19:20 ` Noah Goldstein via Libc-alpha
2021-09-27 19:34 ` Florian Weimer via Libc-alpha
2021-09-27 19:43 ` Noah Goldstein via Libc-alpha
2021-09-27 19:59 ` Florian Weimer via Libc-alpha
2021-09-27 20:22 ` Noah Goldstein via Libc-alpha
2021-09-27 20:24 ` Florian Weimer via Libc-alpha
2021-09-27 20:38 ` Noah Goldstein via Libc-alpha
2021-09-28 0:07 ` Noah Goldstein via Libc-alpha
2021-09-27 17:42 ` Joseph Myers
2021-09-27 17:48 ` Noah Goldstein via Libc-alpha
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.22.394.2109142351240.1167011@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=goldstein.w.n@gmail.com \
--cc=libc-alpha@sourceware.org \
/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).