|
From: | Dmitry Gutov |
Subject: | Re: native-comp-async-report-warnings-errors default value |
Date: | Sat, 8 Jan 2022 04:29:42 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 |
On 30.12.2021 11:37, Andrea Corallo wrote:
Indeed it has effect in the runtime. But as you say this is because the byte compiler generates different code for that (in this case a top level form). In the case of the native compiler we'd need to store and reuse a bunch of information for following native compilation that has to happen after.
Store in .elc files, I take it.
But...As the bytecompiler pipeline was always assumed to be the only and last compilation step, bytecode is ATM not designed to retain these information. I'm sure it's extensible somehow but we probably need some advise on what's the best way to approach this....I suppose you might want to access that information without evaluating said additional byte code forms either. Or could it evaluate them anyway? If native compilation happens after the code is loaded, the symbols will have the necessary properties then.Maybe a sufficient solution is an ad hoc local variable emitted (when necessary) in the .elc file with like an a-list function -> declaration specifiers we are interested in?
I was even going to suggest that you would parse those (byte-code ...) forms in compiled files -- as long as they actually vary very little, it could be handled by a small interpreter.
But maybe we could keep those forms uncompiled without a significant performance downside? Someone could benchmark that. Then the .elc files would just contain (function-put ...) on top-level instead.
Or if you really need the declarations available before the corresponding functions are defined (I don't know if you compile every encountered function right away, or wait until the whole file is parsed), the order of forms in .elc files could be swapped: first property declaration, then definition.
[Prev in Thread] | Current Thread | [Next in Thread] |