Re: Suppressing native compilation (short and long term)

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

Ah I see.  We could allow for disabling completely native compilation,
but that's something different from what those two customizes are for.

That said I think that given the very low cost of building trampolines,
and the deep impact that their absence would have in the Emacs
machinery, we should acctually discourage the user to do so unless some
very specific reason is present (I can't think of any ATM).

  Andrea