From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: HAVE_FAST_UNALIGNED_ACCESS Date: Sat, 01 Apr 2023 11:19:19 +0300 Message-ID: <83lejcypyw.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2032"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, vibhavp@gmail.com, rpluim@gmail.com, emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 01 10:19:48 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 1piWSi-0000HP-2u for ged-emacs-devel@m.gmane-mx.org; Sat, 01 Apr 2023 10:19:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1piWS1-0003XE-OI; Sat, 01 Apr 2023 04:19:05 -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 1piWS0-0003X0-E1 for emacs-devel@gnu.org; Sat, 01 Apr 2023 04:19:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1piWS0-000533-4l; Sat, 01 Apr 2023 04:19:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=eZWXIrtcQeyFQFKg7unFHC21aokMY0dkSBmql2G1Ei8=; b=rJR6ims4FZUgIBEITklO 3Z787MmK87MT264MN4ipsi+sUu6EuiX2PM40oolvMVDug6coAvDr330jYxU4wwgU25+lhlGDmZEQb ZHMkaOVnccOp+7Ee9bIdHR0O25VOw6tbr6+GuvxIPpdVFdBkuTpLrqmauJYNv+alWMmTMvzIW0wuv 22xFMtxVXmFXHg3Z2SiiQDTfe9OAoNBN2VG3aaV94Ub5yo8CG0c+Ho6RJB1g+h/TVh9iU5kDoZ3Ki tFXIZF4HrPrGpCNCFeie2ceOQCsLrnTrB7/oXOX30obuzXFvBI1rI6sn09MY6s8Ir+PGiGD1FSfHW 6o8mIH4+xKI5pA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1piWRz-0005rv-C0; Sat, 01 Apr 2023 04:19:03 -0400 In-Reply-To: <63A29442-4C0C-4C3C-B40E-4A3DB91E3009@gmail.com> (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Sat, 1 Apr 2023 09:42:53 +0200) 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:304978 Archived-At: > From: Mattias Engdegård > Date: Sat, 1 Apr 2023 09:42:53 +0200 > Cc: Po Lu , > vibhavp@gmail.com, > rpluim@gmail.com, > emacs-devel@gnu.org > > 1 apr. 2023 kl. 08.39 skrev Eli Zaretskii : > > > I don't want to make changes on the release branch without a positive > > evidence that the existing code causes verifiable problems. And even > > then I prefer to make changes only for platforms where those problems > > happen. > > I'm not overly worried about the code, but to put this matter to rest, what about simply dropping the vectorisation altogether, on all platforms, in Emacs 29? That should be very safe. >From my POV, the safest code is the one we have, because that have lived for many moons and have been used by many people, with no problems reported so far. Which is why I said above that I want to see verifiable problems with the existing code, and understand those problems well enough, before I will agree to such non-trivial changes on the release branch IOW, "best engineering practices" are for master; on the release branch, using existing code proven by time takes precedence, because our ability to predict consequences is limited.