[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: DEFINE-OPTIMIZER (Version 2)
- To: CL-Compiler@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Issue: DEFINE-OPTIMIZER (Version 2)
- From: cperdue@Sun.COM (Cris Perdue)
- Date: Fri, 10 Mar 89 14:35:06 PST
Optimizers are important in my experience also. In fact, I would
have sat down on Saturday to write a similar proposal had Kent
not distributed this one.
I support Kent's proposal, with the following suggestions:
An additional function that corresponds to MACRO-FUNCTION for ordinary
macros. I include the proposed definition for this, which follows the
definition of MACRO-FUNCTION in CLtL, p144. This provides
primitive-level access, including the ability to undefine an
Add to the problem description that sometimes an "operator" is defined
as a macro purely because its performance would be inadequate if
implemented as a function.
Also, I believe it would be best to state that in environments where
the compiler is prohibited from treating a function as INLINE,
optimizers are deactivated. In particular, the functions
OPTIMIZE-EXPRESSION and OPTIMIZE-EXPRESSION-1 do not transform their
expression argument if given an environment in which the function must
not be treated as INLINE. (I recognize that this is a bit of
a judgment call.)
The point here is to make user-defined optimizers follow the behavior
of optimizers built-in to compilers in their response to NOTINLINE.
This function corresponds directly to MACRO-FUNCTION for macros.
The argument must be a symbol. If the symbol has an optimizer
defined, then the optimizer function is returned. An optimizer
function takes two arguments, the expression that may be
optimized and an environment of the same kind accepted by macro
expansion functions. If the symbol has no optimizer, then NIL is
SETF may be used with OPTIMIZER-FUNCTION to install or change an
optimizer. If NIL is given as the new value, any existing optimizer
definition is removed.