From: Philip Kaludercic <philipk@posteo.net>
To: Felician Nemeth <felician.nemeth@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: (byte-compile '(append '(1 2) '(3 4)))
Date: Sat, 16 Mar 2024 12:46:15 +0000 [thread overview]
Message-ID: <87cyrubazs.fsf@posteo.net> (raw)
In-Reply-To: <87r0gatlqz.fsf_-_@betli.tmit.bme.hu> (Felician Nemeth's message of "Sat, 16 Mar 2024 13:16:36 +0100")
[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]
Felician Nemeth <felician.nemeth@gmail.com> writes:
> (disassemble (byte-compile '(append '(1 2) '(3 4))))
>
> resuts in
>
> byte code:
> args: nil
> 0 constant append
> 1 constant (1 2)
> 2 constant (3 4)
> 3 call 2
> 4 return
>
> Instead I expected it to be something like
>
> byte code:
> args: nil
> 0 constant 1
> 1 constant 2
> 2 constant 3
> 3 constant 4
> 4 list4
> 5 return
>
> I've never looked at byte-code optimization before, and I'm guessing
> this is not a huge improvement, but I still wonder when all the
> arguments of side-effect-free function are constants would it make sense
> to calculate the result at compile time.
`byte-optimize-append' mentions:
;; There is (probably) too much code relying on `append' to return a
;; new list for us to do full constant-folding; these transformations
;; preserve the allocation semantics.
I am not sure what the danger is in the case of constant, quoted lists,
but I am not familiar with the byte compiler either. It seems like this
[-- Attachment #2: Type: text/plain, Size: 650 bytes --]
diff --git a/lisp/emacs-lisp/byte-opt.el b/lisp/emacs-lisp/byte-opt.el
index f75be3f71ad..e6f18590705 100644
--- a/lisp/emacs-lisp/byte-opt.el
+++ b/lisp/emacs-lisp/byte-opt.el
@@ -1599,6 +1599,12 @@ byte-optimize-append
(cdr args))
(cdr newargs)))
+ ;; (append '(C1...) ... '(C2...)) -> (append C1... ... C2...)
+ ((cl-loop for arg in args
+ always (and (eq (car arg) 'quote)
+ (proper-list-p (cdr arg))))
+ `',(mapcan #'cadr args))
+
;; non-terminal arg
((cdr args)
(cond
[-- Attachment #3: Type: text/plain, Size: 151 bytes --]
would do the trick, and the byte-code is even better:
byte code:
args: nil
0 constant (1 2 3 4)
1 return
--
Philip Kaludercic on peregrine
next prev parent reply other threads:[~2024-03-16 12:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87v8j28c2x.fsf@betli.tmit.bme.hu>
[not found] ` <874jdipfp5.fsf@posteo.net>
[not found] ` <87cys6t734.fsf@betli.tmit.bme.hu>
[not found] ` <87r0gmnjq4.fsf@posteo.net>
[not found] ` <87o7bprr04.fsf@betli.tmit.bme.hu>
[not found] ` <87bk7p57yz.fsf@posteo.net>
2024-03-16 12:16 ` (byte-compile '(append '(1 2) '(3 4))) Felician Nemeth
2024-03-16 12:46 ` Philip Kaludercic [this message]
2024-03-16 13:23 ` Basil L. Contovounesios
2024-03-16 13:45 ` Felician Nemeth
2024-03-16 13:55 ` Philip Kaludercic
2024-03-16 23:42 ` Basil L. Contovounesios
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cyrubazs.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=emacs-devel@gnu.org \
--cc=felician.nemeth@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).