From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: 'GNU C Library' <libc-alpha@sourceware.org>,
Noah Goldstein <goldstein.w.n@gmail.com>
Subject: [PATCH] elf: Replace memcmp with __memcmpeq for variable size
Date: Tue, 8 Feb 2022 22:30:17 +0000 [thread overview]
Message-ID: <AS8PR08MB65348A28096A70EC1D9A4EE0832D9@AS8PR08MB6534.eurprd08.prod.outlook.com> (raw)
Hi,
>> My understanding is this optimization would eventually be implemented by
>
> What kinds of codes should compilers generate? For glibc internal
> usage, we can write codes in such a way that the generated codes
> are very similar to what compilers should generate.
>
>> the compiler, so maybe it would be better to let it optimize if suitable
>> (similar to what we are aiming for math code).
I agree with Joseph that these kind of micro-optimizations are generally counter productive -
we've removed many similar hacks from math libraries resulting in good speedups (they
almost always work against you, blocking compiler optimizations such as inlining, constant
propagation etc). It's much better to improve code via algorithm or implementation
optimizations rather than focus on these micro-optimizations.
As mentioned, codesize will increase since many applications now use both memcmp and
__memcmpeq, and the extra I-cache misses may wipe out any savings.
Cheers,
Wilco
next reply other threads:[~2022-02-08 22:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 22:30 Wilco Dijkstra [this message]
2022-02-08 23:00 ` Adhemerval Zanella
2022-02-09 0:07 ` Noah Goldstein
2022-02-09 1:42 ` Wilco Dijkstra
-- strict thread matches above, loose matches on Subject: below --
2022-02-06 21:09 H.J. Lu
2022-02-06 22:19 ` Florian Weimer
2022-02-07 0:20 ` H.J. Lu
2022-02-07 10:40 ` Florian Weimer
2022-02-07 13:13 ` H.J. Lu
2022-02-07 13:19 ` Florian Weimer
2022-02-07 13:27 ` H.J. Lu
2022-02-07 13:30 ` Adhemerval Zanella
2022-02-07 14:00 ` H.J. Lu
2022-02-07 20:35 ` Joseph Myers
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=AS8PR08MB65348A28096A70EC1D9A4EE0832D9@AS8PR08MB6534.eurprd08.prod.outlook.com \
--to=wilco.dijkstra@arm.com \
--cc=goldstein.w.n@gmail.com \
--cc=hjl.tools@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).