From: Wilco Dijkstra <Wilco.Dijkstra@arm.com>
To: Florian Weimer <fweimer@redhat.com>,
Wilco Dijkstra via Libc-alpha <libc-alpha@sourceware.org>
Cc: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
Subject: Re: [PATCH 0/5] Added optimized memcpy/memmove/memset for A64FX
Date: Fri, 30 Apr 2021 15:40:00 +0000 [thread overview]
Message-ID: <VE1PR08MB5599D2DC2EAA05773AAC5CA1835E9@VE1PR08MB5599.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <87eeer4woe.fsf@oldenburg.str.redhat.com>
Hi Florian,
>> Well it doesn't seem to behave like a NOP. So to avoid slowing down
>> all string functions, bti c must be removed completely, not just from
>> A64FX memcpy. Using a real NOP is fine in all cases as long as
>> HAVE_AARCH64_BTI is not defined.
>
> I'm probably confused, but: If BTI is active, many more glibc functions
> will have BTI markers. What makes the string functions special?
Exactly. And at that point trying to remove it from memcpy is just pointless.
The case we are discussing is where BTI is not turned on in GLIBC but we still
emit a BTI at the start of assembler functions for simplicity. By using a NOP
instead, A64FX will not execute BTI anywhere in GLIBC.
Cheers,
Wilco
next prev parent reply other threads:[~2021-04-30 15:40 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-12 12:52 Wilco Dijkstra
2021-04-12 18:53 ` Florian Weimer
2021-04-13 12:07 ` naohirot
2021-04-14 16:02 ` Wilco Dijkstra
2021-04-15 12:20 ` naohirot
2021-04-20 16:00 ` Wilco Dijkstra
2021-04-27 11:58 ` naohirot
2021-04-29 15:13 ` Wilco Dijkstra
2021-04-30 15:01 ` Szabolcs Nagy
2021-04-30 15:23 ` Wilco Dijkstra
2021-04-30 15:30 ` Florian Weimer
2021-04-30 15:40 ` Wilco Dijkstra [this message]
2021-05-04 7:56 ` Szabolcs Nagy
2021-05-04 10:17 ` Florian Weimer
2021-05-04 10:38 ` Wilco Dijkstra
2021-05-04 10:42 ` Szabolcs Nagy
2021-05-04 11:07 ` Florian Weimer
2021-05-06 10:01 ` naohirot
2021-05-06 14:26 ` Szabolcs Nagy
2021-05-06 15:09 ` Florian Weimer
2021-05-06 17:31 ` Wilco Dijkstra
2021-05-07 12:31 ` naohirot
2021-04-19 2:51 ` naohirot
2021-04-19 14:57 ` Wilco Dijkstra
2021-04-21 10:10 ` naohirot
2021-04-21 15:02 ` Wilco Dijkstra
2021-04-22 13:17 ` naohirot
2021-04-23 0:58 ` naohirot
2021-04-19 12:43 ` naohirot
2021-04-20 3:31 ` naohirot
2021-04-20 14:44 ` Wilco Dijkstra
2021-04-27 9:01 ` naohirot
2021-04-20 5:49 ` naohirot
2021-04-20 11:39 ` Wilco Dijkstra
2021-04-27 11:03 ` naohirot
2021-04-23 13:22 ` naohirot
-- strict thread matches above, loose matches on Subject: below --
2021-03-17 2:28 Naohiro Tamura
2021-03-29 12:03 ` Szabolcs Nagy
2021-05-10 1:45 ` naohirot
2021-05-14 13:35 ` Szabolcs Nagy
2021-05-19 0:11 ` naohirot
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=VE1PR08MB5599D2DC2EAA05773AAC5CA1835E9@VE1PR08MB5599.eurprd08.prod.outlook.com \
--to=wilco.dijkstra@arm.com \
--cc=Szabolcs.Nagy@arm.com \
--cc=fweimer@redhat.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).