> The next one is to do some "whole program analysis", but that is more
> difficult.
Can you do that with Lisp? I figured that since the compiler was
available even to running code that "whole program analysis" would not
be possible.
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
Jonathan Bartlett wrote:
> > The next one is to do some "whole program analysis", but that is more
> > difficult.
>
> Can you do that with Lisp? I figured that since the compiler was
> available even to running code that "whole program analysis" would not
> be possible.
Sure, you just have to have multiple versions. For example, at high
enough optimisation levels(?), SBCL will provide multiple entry points
into the same function, one with argument checking and the other
without. The public entry point does argument checking, but the
compiler can always skip that if it (statically) knows that the
arguments are OK. A more high-level description of a solution would be:
(defun a ...)
(defun b ...)
could be transformed in:
(defun a ...
(labels ((a ...)
(b ...))))
(defun b ...
(labels ((a ...)
(b ...))))
[It'd probably be useful to remove definitions for functions that
aren't used ;)]
All the public entry points are preserved, but having all the called
functions in labels allows the compiler to transform them a lot more.
Of course, that's going to cause a lot of code duplication, but that's
not a rare problem, and I'm sure you can find papers describing decent
approaches to code duplication in specialisation.
Paul Khuong
Jonathan Bartlett wrote:
>
>> The next one is to do some "whole program analysis", but that is more
>> difficult.
>
>
> Can you do that with Lisp? I figured that since the compiler was
> available even to running code that "whole program analysis" would not
> be possible.
If there are calls to functions elsewhere in the same file, the file
compiler can assume that the functions will not be dynamically
redefined (unless the function is declared NOTINLINE). See
section 3.2.2.3 of the CL standard this and other semantic
constraints on conforming programs.
One can also imagine whole-program analysis that performs transforms
that are undone (and possible redone, dynamically) if the program
changes on the fly. I don't know if any existing CL implementations
do this.
Paul