Re: Issue: DEFINE-OPTIMIZER

[David N Gray <Gray@DSG.csc.ti.com>]

> Proposal (DEFINE-OPTIMIZER:NEW-FACILITY):
> 
>   Introduce a facility for declaring compiler optimizations.
> 
>   DEFINE-OPTIMIZER name arglist &body forms

I assume you meant to say that this is a macro rather than a function.

> Current Practice:
...
> Cost to Implementors:

The Explorer's optimization facility is close enough to this that I could
implement the DEFINE-OPTIMIZER macro without having to make any changes to
the compiler.

>   Information about argument type can come from two different sources:
>   THE and declarations (via PROCLAIM or DECLARE).

There is a third source -- certain functions are known to always return a
particular type.  For example, the result of SYMBOL-NAME is always a
string.  Or maybe you intended that to be included in declarations of
functions?

>        While a separate proposal
>   for allowing program access to type declarations would be make this
>   facility more useful, it is still quite useful without it.

The problem with accessing type information from a user-written optimizer
is that it is much easier for the compiler to recognize the type of a form
after it has done certain processing on it (including macro expansion,
source-level optimization, value propagation, and constant folding) than
when looking at raw source.  Consequently, optimizations that depend on
the types of the arguments are most effectively done in a bottom-up
manner.  An optimizer working at that level can't be portable because it
is dealing with the peculiarities of partially compiled code.
Consequently, rather than provide a way for user-written optimizers to
access type declarations, we have a macro which will cause bottom-up
optimization to do simple transformations based on the types of the
arguments.  For example, part of your example can be done by
  (COMPILER:OPTIMIZE-PATTERN (STRING-APPEND STRING STRING)
                             (STRING-APPEND-REAL-STRINGS 1 2))
which says to replace a call to STRING-APPEND with two arguments which are
both known to be strings with a call to STRING-APPEND-REAL-STRINGS using
the same arguments.  I'm not suggesting this for standardization, but I
think this approach could be more reliably portable than a programmatic
interface to type declarations.