[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#67005: 30.0.50; improve nadivce/comp/trampoline handling
From: |
Jens Schmidt |
Subject: |
bug#67005: 30.0.50; improve nadivce/comp/trampoline handling |
Date: |
Tue, 21 Nov 2023 23:10:52 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
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
>> 874jhv9921.fsf@sappc2.fritz.box/">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.
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, (continued)
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Stefan Monnier, 2023/11/08
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Jens Schmidt, 2023/11/12
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Jens Schmidt, 2023/11/14
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Stefan Monnier, 2023/11/14
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Jens Schmidt, 2023/11/15
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Jens Schmidt, 2023/11/20
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Stefan Monnier, 2023/11/20
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Andrea Corallo, 2023/11/21
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling,
Jens Schmidt <=
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Stefan Monnier, 2023/11/21
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Andrea Corallo, 2023/11/22
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Stefan Monnier, 2023/11/22
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Eli Zaretskii, 2023/11/22
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Andrea Corallo, 2023/11/23
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Stefan Monnier, 2023/11/23
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Andrea Corallo, 2023/11/23
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Jens Schmidt, 2023/11/22
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Eli Zaretskii, 2023/11/23
- bug#67005: 30.0.50; improve nadivce/comp/trampoline handling, Andrea Corallo, 2023/11/23