Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: rlb@defaultvalue.org, emacs-devel@gnu.org
> Date: Thu, 29 Sep 2022 08:18:08 +0000
> 
> >> >> Yes `native-comp-deferred-compilation' AFAIK does exactly this already,
> >> >> `native-comp-available-p' is to check if the native compiler is
> >> >> available (not necessarily the deferred/async mechanism).
> >> >
> >> > But then it should disable the trampolines as well, see startup.el.
> >> 
> >> Not in my opinion, trampolines are not deferred async compilation.
> >> 
> >> Also as mentioned ATM is not possible to disable trampolines and have a
> >> fully working native comp Emacs (if we assume primitives can be
> >> redefined).
> >
> > I'm confused.  I alluded to this part of startup.el:
> >
> >     (when (featurep 'native-compile)
> >       (unless (native-comp-available-p)
> >         ;; Disable deferred async compilation and trampoline synthesis
> >         ;; in this session.  This is necessary if libgccjit is not
> >         ;; available on MS-Windows, but Emacs was built with
> >         ;; native-compilation support.
> >         (setq native-comp-deferred-compilation nil
> >               comp-enable-subr-trampolines nil))
> >
> > The last part disables trampolines, AFAIU.  So what am I missing here?
> 
> Hi Eli,
> 
> yes it does, what do you find confusing about this?
> 
> This is how I see things, we have two compilation mechanisms:
> 
> 1- Syncronous native compilation.  This can be triggered:
>    1.1- By the user (calling `native-compile').
>    1.2- By Emacs in the need of generating a trampoline.
> 
> 2- Async/deferred/jit (or how we wanna call it), this is triggered
>    automatically when loafing a .elc with no corresponding .eln.
> 
> We have two customize to control the two automatic mechanisms:
> `comp-enable-subr-trampolines' gates 1.2,
> `native-comp-deferred-compilation' gates 2.
> 
> Indeed `native-comp-available-p' gates all native compilations.

So I was asking whether when the user wants to disable native
compilations, we should disable both 2 and 1.2.  We already do that
when Emacs detects at startup that it doesn't have access to
libgccjit, so why not do the same when the user wants to disable
native compilations for whatever reasons?  You seem to be saying that
1.2 cannot be disabled in that case?  But if so, how come we do
disable it in startup.el?  That is the root of my confusion.

Thanks.