From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arsen =?utf-8?Q?Arsenovi=C4=87?= Newsgroups: gmane.emacs.devel Subject: Re: HAVE_FAST_UNALIGNED_ACCESS Date: Sat, 01 Apr 2023 14:59:53 +0200 Message-ID: <87lejbpxkm.fsf@aarsen.me> References: <87sfdmlgzx.fsf@gmail.com> <94d3de92c50a96d9172f88462bf3bc9c2792600c.camel@gmail.com> <83mt3s244o.fsf@gnu.org> <875yagtopn.fsf@yahoo.com> <838rfc17ja.fsf@gnu.org> <871ql4t8ph.fsf@yahoo.com> <83wn2wyuli.fsf@gnu.org> <63A29442-4C0C-4C3C-B40E-4A3DB91E3009@gmail.com> <83lejcypyw.fsf@gnu.org> <87wn2wrmgc.fsf@yahoo.com> <83bkk7zvxl.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="40823"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , mattias.engdegard@gmail.com, vibhavp@gmail.com, rpluim@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 01 15:01:01 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 1piaqr-000API-Lq for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Apr 2023 15:01:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1piapy-0002PC-5A; Sat, 01 Apr 2023 09:00:06 -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 1piapw-0002Os-LP for emacs-devel@gnu.org; Sat, 01 Apr 2023 09:00:04 -0400 Original-Received: from mout-p-103.mailbox.org ([2001:67c:2050:0:465::103]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1piapu-0004ck-Lt; Sat, 01 Apr 2023 09:00:04 -0400 Original-Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4Ppcgw4sQfz9sWv; Sat, 1 Apr 2023 14:59:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aarsen.me; s=MBO0001; t=1680353996; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=87L40BFVzAnWdFk2iVlzeXw4/+XBypjDF5J8DCUHQIg=; b=R2e/ZwlGLyMrBhTTEgFE4NTGi0hSk7PfYgH2G2QOgVw8W+QJyEmG852wNLSsXRtYgIDmsR PJsVALlwSvB4WW1wGaE1MuIY7iHzneQmxbGKePdull4Lk+HIDIa4P2xthswQUysKB2xEE4 UMR/BklaTsT5dNAuv+3BO5H35B4eZS+GMOV2Ha3lbuOUCmrQxQVQF8Na1i9AIEwNW1qybn fKUR0NLKeK8b+aOSwdRgPJs4hTSrmTuiL5ueS96rfl1AxJVbov6SwXDK41Bza/Kv9vZh2/ xFqszMVzL1Qp5Xve9NcLilTlpgxcdELvATTWVB7aHWeSLJAJKWOYL8lVpqGM7Q== In-reply-to: <83bkk7zvxl.fsf@gnu.org> X-Rspamd-Queue-Id: 4Ppcgw4sQfz9sWv Received-SPF: pass client-ip=2001:67c:2050:0:465::103; envelope-from=arsen@aarsen.me; helo=mout-p-103.mailbox.org X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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:304995 Archived-At: --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Eli Zaretskii writes: > I'm still unconvinced, and I said already what will have a chance of > convincing me: a specific report about a problem this particular code > causes on a specific existing platform we support in Emacs 29 and with > a specific compiler. Similar (but not exactly the same) loops as this one have been shown to generate incorrect code in this thread. It's not a large leap for it to happen to this one, introducing subtle errors for a bit of code that is completely unnecessary (as demonstrated by it being optional), especially at higher optimization levels, where the compiler could easily produce better code than the assumption of a 'mov' would. Is the following trivial enough for 29? --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Remove-aliasing-violation-in-Fstring_lessp.patch Content-Transfer-Encoding: quoted-printable Content-Description: [PATCH] Remove aliasing violation in Fstring_lessp From=2096d75e78358d6c2643bfb7cc65744b8a6178c9d2 Mon Sep 17 00:00:00 2001 From: =3D?UTF-8?q?Arsen=3D20Arsenovi=3DC4=3D87?=3D Date: Sat, 1 Apr 2023 14:25:12 +0200 Subject: [PATCH] Remove aliasing violation in Fstring_lessp * src/fns.c (Fstring_lessp) : Remove strict aliasing violation. =2D-- src/fns.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/src/fns.c b/src/fns.c index ff364c6..e3e11e2 100644 =2D-- a/src/fns.c +++ b/src/fns.c @@ -499,10 +499,16 @@ DEFUN ("string-lessp", Fstring_lessp, Sstring_lessp, = 2, 2, 0, /* First compare entire machine words. */ typedef size_t word_t; int ws =3D sizeof (word_t); =2D const word_t *w1 =3D (const word_t *) SDATA (string1); =2D const word_t *w2 =3D (const word_t *) SDATA (string2); =2D while (b < nb - ws + 1 && w1[b / ws] =3D=3D w2[b / ws]) =2D b +=3D ws; + while (b < nb - ws + 1) + { + word_t w1; + word_t w2; + memcpy (&w1, SDATA (string1) + b, sizeof (w1)); + memcpy (&w2, SDATA (string2) + b, sizeof (w2)); + if (w1 !=3D w2) + break; + b +=3D ws; + } } =20 /* Scan forward to the differing byte. */ =2D-=20 2.40.0 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable .. or something similar to it, assuming I made an error, which is likely given the circumstances. This does pass the testsuite, anyway. It should just expand deferences into explicit memcpys. No actual memcpy calls are produced, and this is at least functional on a superset of compilers, and I suspect replacing the whole thing with a naive-looking while (*(w1++) !=3D *(w2++)); loop would be even better (but I can settle for that being too experimental). =2D-=20 Arsen Arsenovi=C4=87 --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iIYEARYKAC4WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZCgqyRAcYXJzZW5AYWFy c2VuLm1lAAoJEFLClDAeosSTtw0BAI87ceDbkkBioK25T0+6qbJ6FpMmgJE+r8MS aO39TaWiAQCavLG022ejp5We2MZcnTTjrXgt97vPjokV8MxJaWOMDg== =J2JQ -----END PGP SIGNATURE----- --==-=-=--