GNU bug report logs - #78394
31.0.50; Questions about native-comp-speed and type decl

Previous Next

Full log

Message #26 received at 78394 <at> debbugs.gnu.org (full text, mbox):

From: "Yue Yi" <include_yy <at> qq.com>
To: "Andrea Corallo" <acorallo <at> gnu.org>
Cc: Eli&nbsp;Zaretskii <eliz <at> gnu.org>,
 78394 <78394 <at> debbugs.gnu.org>
Subject: Re: bug#78394: 31.0.50;
 Questions about native-comp-speed and type decl
Date: Mon, 30 Jun 2025 19:34:02 +0800

[Message part 1 (text/plain, inline)]

Thanks, Eli and Andrea. Date: Mon, 30 Jun 2025 03:31:53 -0400, Andrea Corallo writes, > > Another question is about `compilation-safety'. As I understand it, when > > set to 1, it prevents Emacs from crashing due to faulty > > optimizations. Does this mean the variable only guards against the most > > severe cases, rather than ensuring the correctness of optimizations in > > general? >  > The doc for compilation-safety says: >  > "Possible values are: >   0 - emitted code can misbehave, even crash Emacs, if declarations of >       functions do not correctly describe their actual behavior; >   1 - emitted code is to be generated in a safe manner, even if functions >       are mis-declared." >  > The situation for 'compilation-safety' with the current code in case of > incorrect declarations is: >  > 0 we perform optimizations, code can even crash. > 1 it cannot crash but still we can perform some otimizations (which can >   produce unexpected results at execution time). Thank you for the explanation -- I now understand that when `compilation-safety' is set to 1 (the default), it generates code in a safer manner that avoids crashes, even if function declarations are incorrect. However, it does *not* guarantee the correctness of the generated code in such cases. > If we are unsatisfied with this granularity we could introduce a new value: >  > 2 no optimizations are performed based on function type declarations. >  > Mmmh maybe is not a bad idea. Mmm, I somewhat agree with this idea. I actually discovered the consequences of incorrect type declarations while running code under ERT tests, but it¡¯s a kind of issue that's not immediately obvious as being caused by a misdeclared type. If adding this option wouldn¡¯t be too much trouble, please consider implementing it. TIA! By the way, would introducing this option affect native-comp-speed? Since if we had a possible value of 2, optimizations wouldn¡¯t rely on type declarations anymore. Another possible improvement might be to clarify the docstring for compilation-safety. I mean, making it more explicitly state that it ensures *safety*, but does not guarantee *correctness*.

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.