GNU bug report logs - #78394
31.0.50; Questions about native-comp-speed and type decl

Previous Next

To reply to this bug, email your comments to 78394 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Yue Yi" <include_yy <at> qq.com>
To: "bug-gnu-emacs" <bug-gnu-emacs <at> gnu.org>
Subject: 31.0.50; Questions about native-comp-speed and type decl
Date: Mon, 12 May 2025 23:55:01 +0800

[Message part 1 (text/plain, inline)]

Hello Emacs maintainers, When modifying an org HTML export backend, I tentatively added type annotations to a function to make the code run faster. However, during unit testing, byte compilation produced correct results, while native compilation did not. Specifically, the following cleaned-up code illustrates the issue: ---------------------------&gt;8<----------------------------- (defconst my/plist '(:html-checkbox-type unicode)) (defconst t-checkbox-types   '(( unicode .       ((on . "�7�1") (off . "�7�0")        (trans . "�7�2"))))) (let ((native-comp-speed 2))   (defun t--checkbox (checkbox info)     "Format CHECKBOX into HTML."     (declare (ftype (function (t plist) string))     (side-effect-free t) (important-return-value t))     (cdr (assq checkbox                (cdr (assq (plist-get info :html-checkbox-type)                           t-checkbox-types)))))   (defun t--format-checkbox (checkbox info)     "Format a CHECKBOX option to string. CHECKBOX can be `on', `off', `trans', or anything else. Returns an empty string if CHECKBOX is not one of the these three."     (declare (ftype (function (t plist) string))     (side-effect-free t) (important-return-value t))     (let ((a (t--checkbox checkbox info)))       (concat a (and a " "))))   ;; native comp   (native-compile 't--checkbox)   (native-compile 't--format-checkbox)) ---------------------------&gt;8<----------------------------- AFACK, the default value of `native-comp-speed' is 2. In this case, the behavior of the following code is inconsistent with that of the byte-compiled or non-compiled code: ---------------------------&gt;8<----------------------------- ;; normal (t--format-checkbox nil my/plist) ;;=&gt; "" ;; byte-code (t--format-checkbox nil my/plist) ;;=&gt; "" ;; speed 1 (t--format-checkbox nil my/plist) ;;=&gt; "" ;; speed 2 (t--format-checkbox nil my/plist) ;;=&gt; " " ---------------------------&gt;8<----------------------------- Of course, we can notice that the type declaration for `t--checkbox' is problematic --- its return type should be (or null string) instead of string. After correcting this mistake, the function works properly under speed=2. In C, we generally avoid aggressive optimizations because they can lead to unpredictable behavior. What I��d like to ask is whether similar situations can occur in Emacs Lisp��s native compilation as well --- like the issue I encountered here? Another question is about `compilation-safety'. As I understand it, when set to 1, it prevents Emacs from crashing due to faulty optimizations. Does this mean the variable only guards against the most severe cases, rather than ensuring the correctness of optimizations in general? Best regards.

[Message part 2 (text/html, inline)]

Message #8 received at 78394 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Yue Yi" <include_yy <at> qq.com>, Andrea Corallo <acorallo <at> gnu.org>
Cc: 78394 <at> debbugs.gnu.org
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Mon, 12 May 2025 19:16:07 +0300

> Date: Mon, 12 May 2025 23:55:01 +0800
> From:  "Yue Yi" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> When modifying an org HTML export backend, I tentatively added type
> annotations to a function to make the code run faster. However, during
> unit testing, byte compilation produced correct results, while native
> compilation did not. Specifically, the following cleaned-up code
> illustrates the issue:
> 
> --------------------------->8<-----------------------------
> (defconst my/plist '(:html-checkbox-type unicode))
> (defconst t-checkbox-types
>   '(( unicode .
>       ((on . "�7�1") (off . "�7�0")
>        (trans . "�7�2")))))
> 
> (let ((native-comp-speed 2))
>   (defun t--checkbox (checkbox info)
>     "Format CHECKBOX into HTML."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (cdr (assq checkbox
>                (cdr (assq (plist-get info :html-checkbox-type)
>                           t-checkbox-types)))))
> 
>   (defun t--format-checkbox (checkbox info)
>     "Format a CHECKBOX option to string.
> 
> CHECKBOX can be `on', `off', `trans', or anything else.
> Returns an empty string if CHECKBOX is not one of the these three."
>     (declare (ftype (function (t plist) string))
>     (side-effect-free t) (important-return-value t))
>     (let ((a (t--checkbox checkbox info)))
>       (concat a (and a " "))))
>   ;; native comp
>   (native-compile 't--checkbox)
>   (native-compile 't--format-checkbox))
> --------------------------->8<-----------------------------
> 
> AFACK, the default value of `native-comp-speed' is 2. In this case, the
> behavior of the following code is inconsistent with that of the
> byte-compiled or non-compiled code:
> 
> --------------------------->8<-----------------------------
> ;; normal
> (t--format-checkbox nil my/plist) ;;=> ""
> ;; byte-code
> (t--format-checkbox nil my/plist) ;;=> ""
> ;; speed 1
> (t--format-checkbox nil my/plist) ;;=> ""
> ;; speed 2
> (t--format-checkbox nil my/plist) ;;=> " "
> --------------------------->8<-----------------------------
> 
> Of course, we can notice that the type declaration for `t--checkbox' is
> problematic --- its return type should be (or null string) instead of
> string. After correcting this mistake, the function works properly under
> speed=2.
> 
> In C, we generally avoid aggressive optimizations because they can lead
> to unpredictable behavior. What I��d like to ask is whether similar
> situations can occur in Emacs Lisp��s native compilation as well --- like
> the issue I encountered here?
> 
> Another question is about `compilation-safety'. As I understand it, when
> set to 1, it prevents Emacs from crashing due to faulty
> optimizations. Does this mean the variable only guards against the most
> severe cases, rather than ensuring the correctness of optimizations in
> general?

I hope Andrea (CC'ed) will be able to answer your questions.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.