[Top][All Lists]

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

Re: native compilation units

From: Lynn Winebarger
Subject: Re: native compilation units
Date: Sat, 11 Jun 2022 12:13:44 -0400

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.  


reply via email to

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