From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sam James Newsgroups: gmane.emacs.devel Subject: Re: HAVE_FAST_UNALIGNED_ACCESS Date: Thu, 30 Mar 2023 12:09:41 +0100 Message-ID: <87tty2ze7f.fsf@gentoo.org> References: <87sfdmlgzx.fsf@gmail.com> <83a5zu5ybx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6138"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.14; emacs 29.0.60 Cc: Robert Pluim , luangruo@yahoo.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 30 13:12:20 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1phqCZ-0001Q8-Ur for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Mar 2023 13:12:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phqBu-0005eM-Rd; Thu, 30 Mar 2023 07:11:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1phqBq-0005e8-Lh for emacs-devel@gnu.org; Thu, 30 Mar 2023 07:11:34 -0400 Original-Received: from woodpecker.gentoo.org ([140.211.166.183] helo=smtp.gentoo.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1phqBo-0003l2-Ii; Thu, 30 Mar 2023 07:11:34 -0400 In-reply-to: <83a5zu5ybx.fsf@gnu.org> Received-SPF: pass client-ip=140.211.166.183; envelope-from=sam@gentoo.org; helo=smtp.gentoo.org X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:304860 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> From: Robert Pluim >> Cc: Po Lu >> Date: Thu, 30 Mar 2023 11:34:42 +0200 >>=20 >> Fstring_lessp has: >>=20 >> /* Check whether the platform allows access to unaligned addresses for >> size_t integers without trapping or undue penalty (a few cycles is OK= ). >>=20 >> This whitelist is incomplete but since it is only used to improve >> performance, omitting cases is safe. */ >> #if defined __x86_64__|| defined __amd64__ \ >> || defined __i386__ || defined __i386 \ >> || defined __arm64__ || defined __aarch64__ \ >> || defined __powerpc__ || defined __powerpc \ >> || defined __ppc__ || defined __ppc \ >> || defined __s390__ || defined __s390x__ >> #define HAVE_FAST_UNALIGNED_ACCESS 1 >> #else >> #define HAVE_FAST_UNALIGNED_ACCESS 0 >> #endif >>=20 >> but even if unaligned access is normally permitted by a machine, it is >> still undefined behavior to dereference an unaligned pointer. > > This is incorrect. There's nothing undefined about x86 unaligned > accesses. C standards can regard this as UB, but we are using > machine-specific knowledge here (and Emacs cannot be built with a > strict adherence to C standards anyway). Things can still go wrong on x86, particularly with SIMD: https://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html. > >> Instead, HAVE_FAST_UNALIGNED_ACCESS and UNALIGNED_LOAD_SIZE should be >> removed and memcpy used instead: >>=20 >> word_t a, c; >>=20 >> memcpy (&a, w1 + b / ws, sizeof a); >> memcpy (&c, w2 + b / ws, sizeof c); >>=20 >> doing so will make the compiler itself generate the right sequence of >> instructions for performing unaligned accesses, normally with only a few >> cycles penalty. > > We don't want that penalty here, that's all. > >> I would like to install such a change on emacs-29. > > No, please don't. > >> Emacs currently crashes when built with various compilers performing >> pointer alignment checks. > > Details, please. Which compilers, on what platforms, for what target > architectures, etc. Unconditionally removing the fast copy there is a > non-starter. I imagine they're referring to UBSAN. Emacs may want to add an annotation where HAVE_FAST_UNALIGNED_ACCESS is used. But for modern compilers, they will indeed DTRT anyway when they see memcpy. See https://github.com/WayneD/rsync/pull/428 for an example. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOQEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZCVuVF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZDnuQD7BzvuziaRHBoVOeLSyJvMPRfk/oH3QkDzGDBH uZFGk5AA+OsNtHSrqZv5r7stCy2iot4vb4HH9wHyMm7DbGuKKQI= =OR6i -----END PGP SIGNATURE----- --=-=-=--