Re: Finalizing 'inhibit-automatic-native-compilation'

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Aymeric Agon-Rambosson <aymeric.agon@yandex.com>
>> Cc: akrl@sdf.org, spwhitton@spwhitton.name, monnier@iro.umontreal.ca,
>>  emacs-devel@gnu.org, larsi@gnus.org, rlb@defaultvalue.org
>> Date: Fri, 10 Feb 2023 09:04:36 +0100
>> 
>> 
>> Le jeudi 9 février 2023 à 09:52, Eli Zaretskii <eliz@gnu.org> a 
>> écrit :
>> 
>> > Are you saying that it is not selective enough, and that in
>> > some cases you needed to disable only trampolines for specific 
>> > subrs?
>> 
>> This is already possible with the variable 
>> `native-comp-never-optimize-functions'.
>> 
>> This is what we've used for the cases I've presented. For 
>> projectile for instance :
>> 
>> (with-eval-after-load 'comp
>>   (push 'insert-file-contents 
>>   native-comp-never-optimize-functions))
>
> Thanks, I'm aware of the variable, but didn't think its effects
> included trampolines.  I guess we need to update the doc string.
>
> Andrea, WDYT?

When a primitive is listed in that variable the generated code will not
call it directly, instead will go through the funcall machinery making
the trampoline unnecessary.  IIRC this will not apply to primitives for
which a dedicated op code exists already in bytecode (those are already
optimized by the byte compiler).

So yeah maybe we should be more verbose on that, but we must be careful
on the wording, primitives like + will still be not re-definable
reliably.

  Andrea