[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Andrea Corallo
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Fri, 10 Feb 2023 17:02:31 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

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


reply via email to

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