From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Fri, 10 Feb 2023 17:02:31 +0000 Message-ID: References: <837cx8cey0.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <87sffo3as7.fsf@melete.silentflame.com> <83v8kkxzzx.fsf@gnu.org> <87r0v811pm.fsf@melete.silentflame.com> <87cz6nxdqy.fsf@X570GP> <87r0uzcnam.fsf@X570GP> <83k00rmg2j.fsf@gnu.org> <87h6vuj697.fsf@X570GP> <83357dlxfi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7247"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Aymeric Agon-Rambosson , spwhitton@spwhitton.name, monnier@iro.umontreal.ca, emacs-devel@gnu.org, larsi@gnus.org, rlb@defaultvalue.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 10 18:03:20 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pQWnw-0001bp-Ig for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Feb 2023 18:03:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQWnL-00021r-FO; Fri, 10 Feb 2023 12:02:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQWnJ-0001uJ-QO for emacs-devel@gnu.org; Fri, 10 Feb 2023 12:02:41 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQWnH-00059A-LA; Fri, 10 Feb 2023 12:02:41 -0500 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 31AH2UkP011193 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 10 Feb 2023 17:02:31 GMT In-Reply-To: <83357dlxfi.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 10 Feb 2023 10:46:57 +0200") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: 14 X-Spam_score: 1.4 X-Spam_bar: + X-Spam_report: (1.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303113 Archived-At: Eli Zaretskii writes: >> From: Aymeric Agon-Rambosson >> 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 >>=20 >>=20 >> Le jeudi 9 f=C3=A9vrier 2023 =C3=A0 09:52, Eli Zaretskii = a=20 >> =C3=A9crit : >>=20 >> > Are you saying that it is not selective enough, and that in >> > some cases you needed to disable only trampolines for specific=20 >> > subrs? >>=20 >> This is already possible with the variable=20 >> `native-comp-never-optimize-functions'. >>=20 >> This is what we've used for the cases I've presented. For=20 >> projectile for instance : >>=20 >> (with-eval-after-load 'comp >> (push 'insert-file-contents=20 >> 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