bug-gnu-emacs
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]