From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Newsgroups: gmane.emacs.devel Subject: Re: byte-code optimizations Date: Sat, 18 Sep 2004 16:26:04 -0400 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409181152.15364.pogonyshev@gmx.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1095539213 2235 80.91.229.6 (18 Sep 2004 20:26:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 18 Sep 2004 20:26:53 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 18 22:26:44 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C8ln9-00071n-00 for ; Sat, 18 Sep 2004 22:26:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8lsw-00038f-U9 for ged-emacs-devel@m.gmane.org; Sat, 18 Sep 2004 16:32:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C8lsn-00037p-N2 for emacs-devel@gnu.org; Sat, 18 Sep 2004 16:32:33 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C8lsm-00037P-Fq for emacs-devel@gnu.org; Sat, 18 Sep 2004 16:32:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C8lsm-000378-CM for emacs-devel@gnu.org; Sat, 18 Sep 2004 16:32:32 -0400 Original-Received: from [206.47.199.141] (helo=simmts12-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C8lmW-0008Fe-HQ for emacs-devel@gnu.org; Sat, 18 Sep 2004 16:26:04 -0400 Original-Received: from empanada.home ([67.68.216.197]) by simmts12-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20040918202457.JPP1580.simmts12-srv.bellnexxia.net@empanada.home>; Sat, 18 Sep 2004 16:24:57 -0400 Original-Received: by empanada.home (Postfix, from userid 502) id A17162F114D; Sat, 18 Sep 2004 16:26:04 -0400 (EDT) Original-To: Paul Pogonyshev In-Reply-To: <200409181152.15364.pogonyshev@gmx.net> (Paul Pogonyshev's message of "Sat, 18 Sep 2004 11:52:15 -0200") User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (darwin) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27249 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27249 > + ;; dup varbind-X [car/cdr ...] unbind-1 --> [car/cdr ...] I get the same optimization result by adding car/cdr/equal/nth unbind --> unbind car/cdr/equal/nth Problem is that such an optimization is only safe if car/cdr/... is not affected by the bound thing. If the `unbind' unbinds a variable, then I think it's always safe. So I've added to the lapcode optimizer some logic to keep track of the specpdl stack so that I can distinguish an unbind that terminates a varbind from one that terminates an unwind-protect. Better yet: you also get the exact same result code (without any lapcode optimization) if you use (defsubst* cddr (x) (cdr (cdr x))) I.e. using the `defubst*' (from CL). Stefan