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: Wed, 15 Nov 2023 22:47:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [...]

"Yes, I think you're right" to all your previous statements.

> This seems OK: if there's an advice when the code is compiled, there's
> a good chance that the advice will also be present when the code is
> executed, in which case it's more efficient to use a straight `funcall`
> than a "direct" call that gets redirected to `funcall`.

Interesting point.  I thought a native trampoline would be somehow more
efficient than a straight `funcall'.  I agree now to your "-1".

>> ------------------------- snip -------------------------
>> (defun bar () nil)
>> (advice-add 'bar :before 'ignore)
>> (native-compile 'bar)
>>
>> =>
>>
>> comp--native-compile: Native compiler error: bar, "can't native
>> compile an already byte-compiled function"
>> ------------------------- snip -------------------------

> We could tweak `native-compile` and `byte-compile` so they look through
> pieces of advice to try and find the underlying not-yet-compiled
> functions, compile them and re-install them where they were found, but
> obviously, noone asked for that until now and hence noone bothered to do
> that work, most likely because things like (native-compile 'bar) and
> (byte-compile 'bar) are operations used extremely rarely.

TBH, I think it would be sufficient and nice to throw at least a more
meaningful error message along the lines of "(native|byte) compilation
of advised functions not supported".  Subject to a different bug?

>> Another suspectible spot is the following from function `Ffset':
>>
>>   if (!NILP (Vnative_comp_enable_subr_trampolines)
>>       && SUBRP (function)
>>       && !SUBR_NATIVE_COMPILEDP (function))
>>     CALLN (Ffuncall, Qcomp_subr_trampoline_install, symbol);
>
> Actually, I don't understand this code now that I re-(re-)*read it.
> Why do we negate the SUBR_NATIVE_COMPILEDP (function)?

Do you mean "why do we negate it" or "why do we have it at all"?  As for
the negation, we have

  SUBR_NATIVE_COMPILEDP (Lisp_Object a)
  {
    return SUBRP (a) && !NILP (XSUBR (a)->native_comp_u);
  }

so a condition

  !NILP (Vnative_comp_enable_subr_trampolines)
  && SUBRP (function)
  && SUBR_NATIVE_COMPILEDP (function))

does not make much sense.

As for the existence of "!SUBR_NATIVE_COMPILEDP" I'll try an answer, but
this is of course again Andrea's domain ... I guess it mirrors the
condition

        (cond
         ((and subrp (not (subr-native-elisp-p f)))
          ;; Trampoline removal.

from `comp-call-optim-form-call'.

But probably your question was why we distinguish in *both* these places
between primitives and native compiled Elisp?  FWIW, I tried removing
both conditions and got errors when making bootstrap:

  Error: native-ice ("../lisp/emacs-lisp/macroexp.el" "missing function
  declaration" byte-compile-constant)





reply via email to

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