From: Jens Schmidt via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: andrea corallo <acorallo@gnu.org>, 67005@debbugs.gnu.org
Subject: bug#67005: 30.0.50; improve nadivce/comp/trampoline handling
Date: Tue, 21 Nov 2023 23:10:52 +0100 [thread overview]
Message-ID: <87bkbmiwpf.fsf@sappc2.fritz.box> (raw)
In-Reply-To: <jwv7cmbdhgc.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 20 Nov 2023 22:35:55 -0500")
Thanks, Stefan and Andrea, for your review.
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> (defcustom native-comp-never-optimize-functions
>> - '(eval
>> - ;; The following two are mandatory for Emacs to be working
>> - ;; correctly (see comment in `advice--add-function'). DO NOT
>> - ;; REMOVE.
>> - macroexpand rename-buffer)
>> + ;; Do not include functions `macroexpand' or `rename-buffer' as
>> + ;; default values here. Despite the previous "DO NOT REMOVE"
>> + ;; warnings these are no longer needed. See also the comment on
>> + ;; `advice--add-function' and bug#67005. FIXME: But do include
>> + ;; `eval' as temporary (?) remedy for bug#67141.
>> + '(eval)
>> "Primitive functions to exclude from trampoline optimization.
>
> I'm not sure I like the idea of keeping the whole history in comments.
> I suggest you try and trim it down to the part that seems likely
> to reoccur, like "We used to list those functions that were advised
> during preload but we now prefer to disallow them in `advice-add`".
Ok.
Only slightly off-topic: When changing the default value of user option
`native-comp-never-optimize-functions', which now both Andrea and I have
done, does one also need to bump the :version? Or is this taken care of
automagically? If it needs to be done manually, to which value should
we/I set it?
>> In `addvice--add-function' I wanted to at least preserve the comment
>> from my initial patch (see attachment to
>> https://yhetil.org/emacs-bugs/874jhv9921.fsf@sappc2.fritz.box/). I
>> think it might help historical research if for that removal there is
>> something that a "git blame" could be hooked onto.
>
> `C-x v h` is your friend. It was weird in the fist place to put the
> trampoline stuff there (e.g. it's specific to functions stored in symbols so
> it would have been more logical to put it into `advice-add` instead), so
> it doesn't seem very likely that this will re-occur.
Also Ok. `C-x v h` is my *new* friend.
>> <<>>"
>> + ;; Actively disallow function advices (here) and advices in general
>> + ;; on primitives (in `comp--install-trampoline') during bootstrap
>> + ;; for the following reasons:
>> + ;; - Advices in Emacs' core are generally considered bad style.
>> + ;; - `Snarf-documentation' looses docstrings of advised dumped
>> + ;; functions (bug#66032#20).
>> + ;; - Native compilation does not generate trampolines for advised
>> + ;; primitives while loadup.el executes.
>
> I don't think this last point is true/relevant, is it?
> IIUC it would use a "normal funcall", which doesn't need a trampoline.
Yup, I got it messed up, again. BTW, it was this test in function
`Fcomp__install_trampoline' which put me on the wrong track:
/* FIXME: add a post dump load trampoline machinery to remove this
check. */
if (will_dump_p ())
signal_error ("Trying to advice unexpected primitive before dumping",
subr_name);
I think during normal bootstrap this test should never fire, since this
function never should be called, since its call is protected by
`native-comp-enable-subr-trampolines'.
>> ;; TODO:
>> ;; - record the advice location, to display in describe-function.
>> - ;; - change all defadvice in lisp/**/*.el.
>> - ;; - obsolete advice.el.
>> + (when purify-flag
>> + (error "Invalid pre-dump advice on %s" symbol))
>> (let* ((f (symbol-function symbol))
>>
>> What do you think?
>
> Beside the comments about the comments, it's a +1 from me.
And here is another comment question: Do you think this snippet that
made me so upset:
(let* ((f (if (symbolp callee)
(symbol-function callee)
(cl-assert (byte-code-function-p callee))
callee))
(subrp (subrp f))
(comp-func-callee (comp-func-in-unit callee)))
deserves some explanation? Along the lines of `subrp' not working as
one might expect on advised primitives, which is exactly what we need
here ...
Will provide a new patch.
next prev parent reply other threads:[~2023-11-21 22:10 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 22:25 bug#67005: 30.0.50; improve nadivce/comp/trampoline handling Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-08 22:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12 19:50 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-14 8:02 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-14 8:31 ` Andrea Corallo
2023-11-14 20:23 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-15 0:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-15 21:47 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-20 23:04 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-21 3:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-21 11:07 ` Andrea Corallo
2023-11-21 22:10 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-11-21 22:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-22 15:40 ` Andrea Corallo
2023-11-22 16:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-22 16:31 ` Eli Zaretskii
2023-11-23 13:02 ` Andrea Corallo
2023-11-23 16:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 20:26 ` Andrea Corallo
2023-11-22 22:01 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 6:19 ` Eli Zaretskii
2023-11-23 15:01 ` Andrea Corallo
2023-11-23 21:13 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 15:00 ` Andrea Corallo
2023-11-23 16:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 16:38 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 20:21 ` Andrea Corallo
2023-11-23 21:36 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 23:48 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 12:41 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 14:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-25 18:35 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-04 20:08 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-04 20:47 ` Andrea Corallo
2023-12-04 23:57 ` Andy Moreton
2023-12-05 17:09 ` Andrea Corallo
2023-12-05 21:32 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-06 0:13 ` Andy Moreton
2023-12-18 21:27 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-23 21:18 ` Jens Schmidt via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-22 14:18 ` Eli Zaretskii
2023-11-16 8:46 ` Andrea Corallo
2023-11-17 15:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-17 20:37 ` Andrea Corallo
2023-11-17 20:44 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-20 8:58 ` Andrea Corallo
2023-11-20 13:13 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-18 7:05 ` Eli Zaretskii
2023-11-20 9:31 ` Andrea Corallo
2023-11-13 9:54 ` Andrea Corallo
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bkbmiwpf.fsf@sappc2.fritz.box \
--to=bug-gnu-emacs@gnu.org \
--cc=67005@debbugs.gnu.org \
--cc=acorallo@gnu.org \
--cc=jschmidt4gnu@vodafonemail.de \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.