From: Alexander Monakov <amonakov@ispras.ru>
To: Ralf Jung <post@ralfj.de>
Cc: Paul Eggert <eggert@cs.ucla.edu>,
Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
libc-alpha <libc-alpha@sourceware.org>
Subject: Re: Support for memcpy with equal source and destination
Date: Mon, 27 Nov 2023 17:25:48 +0300 (MSK) [thread overview]
Message-ID: <9f8ea9e5-f158-3a8a-8585-1f3860700905@ispras.ru> (raw)
In-Reply-To: <feafb774-7495-4e3b-80a5-3d08786c612b@ralfj.de>
On Mon, 27 Nov 2023, Ralf Jung wrote:
> > Please note that GCC does not use memcpy for "sufficiently small" structure
> > copies at -O2, as it's faster to emit the necessary loads+stores inline.
> >
> > The threshold for "sufficiently small" varies with target and compiler
> > version; for instance, it is "above 64 bytes" for 32-bit arm and "above 8192
> > bytes" for x86_64 with current trunk (it also depends on default
> > -march/-mtune, etc.).
>
> Wow, 8 kilobytes?!?
It inlines 'rep movsq' for sizes between 32 and 8192 for generic tuning, but
it varies substantially for different CPU families. For example, with
-mtune=znver[234] the thresholds are:
* memcpy is used above 64 bytes, or if size is unknown
* 'rep movsq' above 16 bytes (up to 64 bytes)
> > So on x86 at least adding such a branch in memcpy is not a practical choice.
>
> Sorry, how does that follow from GCC not using memcpy for small copies?
If you add a branch into memcpy, every single invocation of memcpy will pay a
tiny cost for that branch, even though it matters only for copying huge
structs, which is vanishingly rare compared to all uses of memcpy.
Alexander
next prev parent reply other threads:[~2023-11-27 14:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-23 12:14 Adhemerval Zanella Netto
2023-11-25 7:48 ` Paul Eggert
2023-11-25 8:20 ` Ralf Jung
2023-11-25 17:11 ` Paul Eggert
2023-11-27 11:15 ` Ralf Jung
2023-11-27 11:46 ` Alexander Monakov
2023-11-27 12:34 ` Ralf Jung
2023-11-27 14:25 ` Alexander Monakov [this message]
2023-11-27 14:38 Wilco Dijkstra
2023-11-27 14:45 ` Ralf Jung
2023-11-27 14:53 ` Zack Weinberg
2023-11-27 15:02 ` enh
2023-11-27 19:28 Aaron Peter Bachmann
2023-11-27 19:39 ` Paul Eggert
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=9f8ea9e5-f158-3a8a-8585-1f3860700905@ispras.ru \
--to=amonakov@ispras.ru \
--cc=adhemerval.zanella@linaro.org \
--cc=eggert@cs.ucla.edu \
--cc=libc-alpha@sourceware.org \
--cc=post@ralfj.de \
/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).