From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Small LAP peephole optimization Date: Thu, 10 May 2007 16:10:30 -0400 Message-ID: <65DF6290-AA0C-41F1-B8FC-F2BFBE173064@gnu.org> References: <4641A01D.5080206@yandex.ru> <8835CE25-48D2-4F9A-9DC3-81BC3CE49F4E@gnu.org> <46432A53.5080906@yandex.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1178827845 6095 80.91.229.12 (10 May 2007 20:10:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 10 May 2007 20:10:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 10 22:10:41 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HmEyH-0005GK-JI for ged-emacs-devel@m.gmane.org; Thu, 10 May 2007 22:10:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmF5c-000111-KA for ged-emacs-devel@m.gmane.org; Thu, 10 May 2007 16:18:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HmF5Z-00010s-DW for emacs-devel@gnu.org; Thu, 10 May 2007 16:18:13 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HmF5Y-00010c-1A for emacs-devel@gnu.org; Thu, 10 May 2007 16:18:13 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmF5X-00010Z-QR for emacs-devel@gnu.org; Thu, 10 May 2007 16:18:11 -0400 Original-Received: from rwcrmhc15.comcast.net ([216.148.227.155]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HmEy9-0003bp-Nh; Thu, 10 May 2007 16:10:33 -0400 Original-Received: from raeburn.org (c-65-96-188-63.hsd1.ma.comcast.net[65.96.188.63]) by comcast.net (rwcrmhc15) with ESMTP id <20070510201032m15007kiete>; Thu, 10 May 2007 20:10:32 +0000 Original-Received: from [69.25.196.101] (laptop.raeburn.org [69.25.196.101]) by raeburn.org (8.12.11/8.12.11) with ESMTP id l4AKAV07013592; Thu, 10 May 2007 16:10:31 -0400 (EDT) In-Reply-To: <46432A53.5080906@yandex.ru> X-Mailer: Apple Mail (2.752.3) X-detected-kernel: NetCache Data OnTap 5.x X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:70776 Archived-At: On May 10, 2007, at 10:21, Dmitry Antipov wrote: > What do you think about such 'unsafe' optimizations in general ? As > I know, > some CL systems (such as from Franz) allows byte compiler to be > very aggressive > at the cost of safety. Generally, in the absence of either a directive from the code author saying such assumptions are valid, or some language spec (or other documentation readily available to the code authors) that says that such assumptions may be made in compilation, I don't think such optimizations to valid code are a good idea. > As I understand, branching to +0 is impossible if there is no TAG > between > previous byteop an (byte-constant 0), so we might safely optimize the > sequences like > > (byte-constant 0) (byte-plus . 0) -> on-top-op> I'm not familiar with the representation of byte code in the compiler, but if labels are explicit in the sequence so that you can see that there isn't one there, then yes, that looks correct. > Less obvious cases are also interesting, but I'm not sure that > saving 2 ops > might push someone to implement substantially more complex logic. Right, probably not worthwhile, at least right now. Ken