Re: native compilation units

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On Wed, Jun 8, 2022, 2:56 AM Andrea Corallo <akrl@sdf.org> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>
> >> It's not clear to me whether those points are limited to call
> >> sites or not.
> >
> > I believe it is: the optimization is to replace a call via `Ffuncall` to
> > a "symbol" (which looks up the value stored in the `symbol-function`
> > cell), with a direct call to the actual C function contained in the
> > "subr" object itself (expected to be) contained in the
> > `symbol-function` cell.
> >
> > Andrea would know if there are other semantic-non-preserving
> > optimizations in the level 3 of the optimizations, but IIUC this is very
> > much the main one.
>
> Correct that's the main one: it does that for all calls to C primitives
> and for all calls to lisp function defined in the same compilation unit.
>
> Other than that speed 3 enables pure function optimization and self tail
> recursion optimization.
>

 Would it make sense to add a feature for declaring a function symbol value
is constant and non-advisable, at least within some notion of explicitly
named scope(s)?  That would allow developers to be more selective about
which functions are "exported" to library users, and which are defined as
global function symbols because it's more convenient than wrapping
everything in a package/module/namespace in a giant cl-flet and then
explicitly "exporting" functions and macros via fset.
Then intraprocedural optimization within the named scopes would be
consistent with the language.
I'm thinking of using semantic/wisent for a modern for a proprietary
language.  I am curious whether these optimizations are used or usable in
that context.

Lynn

[-- Attachment #2: Type: text/html, Size: 2393 bytes --]