(if (and (featurep 'xemacs) blah) not optimized anymore

(if (and (featurep 'xemacs) blah) not optimized anymore

[Dan Nicolaescu]

Byte compiling this:

(if (and (featurep 'xemacs) blah)
    (foo))

with emacs-22.1 does not result in any warning, doing it with the
emacs from trunk results in this:

In end of data:
foo.el:2:11:Warning: the function `foo' is not known to be defined.

Any idea what went wrong?

Re: (if (and (featurep 'xemacs) blah) not optimized anymore

[Richard Stallman]

    In end of data:
    foo.el:2:11:Warning: the function `foo' is not known to be defined.

    Any idea what went wrong?

The usual way to find out what went wrong is by debugging what
happens when it fails.  Would someone please?

Re: (if (and (featurep 'xemacs) blah) not optimized anymore

[Stefan Monnier]

> Byte compiling this:

> (if (and (featurep 'xemacs) blah)
>     (foo))

> with emacs-22.1 does not result in any warning, doing it with the
> emacs from trunk results in this:

> In end of data:
> foo.el:2:11:Warning: the function `foo' is not known to be defined.

> Any idea what went wrong?

Stupid typo.  Sorry.  Should be fixed now,


        Stefan

Re: (if (and (featurep 'xemacs) blah) not optimized anymore

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > Byte compiling this:
  > 
  > > (if (and (featurep 'xemacs) blah)
  > >     (foo))
  > 
  > > with emacs-22.1 does not result in any warning, doing it with the
  > > emacs from trunk results in this:
  > 
  > > In end of data:
  > > foo.el:2:11:Warning: the function `foo' is not known to be defined.
  > 
  > > Any idea what went wrong?
  > 
  > Stupid typo.  Sorry.  Should be fixed now,

Thanks!

Can you please take a look at these:

In end of data:
printing.el:6704:1:Warning: the following functions are not known to
be defined: pr-menu-lookup,
    pr-menu-alist, pr-even-or-odd-pages, pr-menu-get-item,
    pr-menu-set-item-name, pr-menu-lock, pr-menu-set-utility-title,
    pr-menu-set-ps-title, pr-menu-set-txt-title, pr-region-active-p,
    pr-do-update-menus, pr-update-mode-line, pr-f-read-string,
    pr-f-set-keymap-parents, pr-keep-region-active

The functions are defined inside a cond. Is the byte compiler supposed
to deal with that?

Re: (if (and (featurep 'xemacs) blah) not optimized anymore

[Stefan Monnier]

> The functions are defined inside a cond. Is the byte compiler supposed
> to deal with that?

Don't kow about "supposed to", but: No, it doesn't deal with that.


        Stefan

Re: (if (and (featurep 'xemacs) blah) not optimized anymore

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > Byte compiling this:
  > 
  > > (if (and (featurep 'xemacs) blah)
  > >     (foo))
  > 
  > > with emacs-22.1 does not result in any warning, doing it with the
  > > emacs from trunk results in this:
  > 
  > > In end of data:
  > > foo.el:2:11:Warning: the function `foo' is not known to be defined.
  > 
  > > Any idea what went wrong?
  > 
  > Stupid typo.  Sorry.  Should be fixed now,

I still see one issue:

After applying this patch: 

--- viper-cmd.el	19 Aug 2007 13:47:07 -0000	1.63
+++ viper-cmd.el	22 Oct 2007 05:37:24 -0000
@@ -861,7 +861,7 @@
 				    (1- (length quail-current-str)))))
 		 ))
 	      ((and viper-special-input-method
-		    viper-xemacs-p
+		    nil
 		    (fboundp 'quail-start-translation))
 	       ;; same as above but for XEmacs, which doesn't have
 	       ;; quail-input-method

the byte compiler will still warn about about quail-start-translation
not being defined. I won't warn if the expression is 
(and nil viper-special-input-method ...)

Re: (if (and (featurep 'xemacs) blah) not optimized anymore

[Stefan Monnier]

> I still see one issue:

> After applying this patch: 

> --- viper-cmd.el	19 Aug 2007 13:47:07 -0000	1.63
> +++ viper-cmd.el	22 Oct 2007 05:37:24 -0000
> @@ -861,7 +861,7 @@
>  				    (1- (length quail-current-str)))))
>  		 ))
>  	      ((and viper-special-input-method
> -		    viper-xemacs-p
> +		    nil
>  		    (fboundp 'quail-start-translation))
>  	       ;; same as above but for XEmacs, which doesn't have
>  	       ;; quail-input-method

> the byte compiler will still warn about about quail-start-translation
> not being defined. I won't warn if the expression is 
> (and nil viper-special-input-method ...)

The patch below seems to fix it, but it does a bit more and I'm not sure
if it behaves well in practice (e.g. performancewise), so please try it
out on a large scale.  If you find it to work well, feel free to
install it.


        Stefan


--- orig/lisp/emacs-lisp/byte-opt.el
+++ mod/lisp/emacs-lisp/byte-opt.el
@@ -185,6 +185,7 @@
 ;;; Code:
 
 (require 'bytecomp)
+(eval-when-compile (require 'cl))
 
 (defun byte-compile-log-lap-1 (format &rest args)
   (if (aref byte-code-vector 0)
@@ -626,12 +628,24 @@
 ;; It is now safe to optimize code such that it introduces new bindings.
 
 ;; I'd like this to be a defsubst, but let's not be self-referential...
-(defmacro byte-compile-trueconstp (form)
-  ;; Returns non-nil if FORM is a non-nil constant.
-  `(cond ((consp ,form) (eq (car ,form) 'quote))
-	 ((not (symbolp ,form)))
-	 ((eq ,form t))
-	 ((keywordp ,form))))
+(defsubst byte-compile-trueconstp (form)
+  "Return non-nil if FORM always evaluates to a non-nil value."
+  (cond ((consp form)
+         (case (car form)
+           (quote (cadr form))
+           (progn (byte-compile-trueconstp (car (last (cdr form)))))))
+        ((not (symbolp form)))
+        ((eq form t))
+        ((keywordp form))))
+
+(defsubst byte-compile-nilconstp (form)
+  "Return non-nil if FORM always evaluates to a nil value."
+  (cond ((consp form)
+         (case (car form)
+           (quote (null (cadr form)))
+           (progn (byte-compile-nilconstp (car (last (cdr form)))))))
+        ((not (symbolp form)) nil)
+        ((null form))))
 
 ;; If the function is being called with constant numeric args,
 ;; evaluate as much as possible at compile-time.  This optimizer
@@ -990,17 +1004,17 @@
     (setq rest form)
     (while (setq rest (cdr rest))
       (cond ((byte-compile-trueconstp (car-safe (car rest)))
-	     (cond ((eq rest (cdr form))
-		    (setq form
-			  (if (cdr (car rest))
-			      (if (cdr (cdr (car rest)))
-				  (cons 'progn (cdr (car rest)))
-				(nth 1 (car rest)))
-			    (car (car rest)))))
+             ;; This branch will always be taken: kill the subsequent ones.
+	     (cond ((eq rest (cdr form)) ;First branch of `cond'.
+		    (setq form `(progn ,@(car rest))))
 		   ((cdr rest)
 		    (setq form (copy-sequence form))
 		    (setcdr (memq (car rest) form) nil)))
-	     (setq rest nil)))))
+	     (setq rest nil))
+            ((and (consp (car rest))
+                  (byte-compile-nilconstp (caar rest)))
+             ;; This branch will never be taken: kill its body.
+             (setcdr (car rest) nil)))))
   ;;
   ;; Turn (cond (( <x> )) ... ) into (or <x> (cond ... ))
   (if (eq 'cond (car-safe form))
@@ -1031,11 +1045,9 @@
                      (byte-optimize-if
                       `(if ,(car (last clause)) ,@(nthcdr 2 form)))))))
           ((byte-compile-trueconstp clause)
-	   (nth 2 form))
-	  ((null clause)
-	   (if (nthcdr 4 form)
-	       (cons 'progn (nthcdr 3 form))
-	     (nth 3 form)))
+	   `(progn ,clause ,(nth 2 form)))
+	  ((byte-compile-nilconstp clause)
+           `(progn ,clause ,@(nthcdr 3 form)))
 	  ((nth 2 form)
 	   (if (equal '(nil) (nthcdr 3 form))
 	       (list 'if clause (nth 2 form))

Re: (if (and (featurep 'xemacs) blah) not optimized anymore

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > > I still see one issue:
  > 
  > > After applying this patch: 
  > 
  > > --- viper-cmd.el	19 Aug 2007 13:47:07 -0000	1.63
  > > +++ viper-cmd.el	22 Oct 2007 05:37:24 -0000
  > > @@ -861,7 +861,7 @@
  > >  				    (1- (length quail-current-str)))))
  > >  		 ))
  > >  	      ((and viper-special-input-method
  > > -		    viper-xemacs-p
  > > +		    nil
  > >  		    (fboundp 'quail-start-translation))
  > >  	       ;; same as above but for XEmacs, which doesn't have
  > >  	       ;; quail-input-method
  > 
  > > the byte compiler will still warn about about quail-start-translation
  > > not being defined. I won't warn if the expression is 
  > > (and nil viper-special-input-method ...)
  > 
  > The patch below seems to fix it, but it does a bit more and I'm not sure
  > if it behaves well in practice (e.g. performancewise), so please try it
  > out on a large scale.  If you find it to work well, feel free to
  > install it.

Thanks!
The bootstrap time from a clean state went from 400s to 402s, so I
checked this in.