[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue DEFINE-OPTIMIZER, version 6
- To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
- Subject: issue DEFINE-OPTIMIZER, version 6
- From: Barry Margolin <barmar@Think.COM>
- Date: Fri, 24 Mar 89 11:22 EST
- Cc: cl-compiler@sail.stanford.edu
- In-reply-to: <8903232118.AA12741@defun.utah.edu>
Date: Thu, 23 Mar 89 14:18:27 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
The editor is advised that a non-binding style note such as the
following would also be appropriate:
In general, it is poor style for a programmer to define optimizers for
functions that he does not maintain. This is because the correct
implementation of an optimizer for a function usually depends on an
understanding of the internals of that function. As such, a function
definition and any optimizers should be maintained as a unit so that
they can changes in either can be synchronized as appropriate with the
other.
I think is is a bit strong. All that an optimizer writer should need to
know is the externally-visible behavior of the function being optimized.
It may be useful to know the implementation of the function in order to
determine what optimizations are most necessary, but it's often possible
to do a decent job without such knowledge. For example, an optimizer
for * that performs constant folding and recognizes the special case
where one argument is the constant 0 is pretty safe, no matter how * is
implemented.
Perhaps what is intended is a warning that programmers shouldn't define
optimizers for standard CL functions that the implementation might
extend, where the optimizer only implements the standard behavior, since
this might break any internal, non-portable uses of the function within
the implementation.
If a function that has an optimizer function is declared INLINE,
the optimizer has precedence. If a function that has an optimizer
function is declared NOTINLINE, the application of the optimizer
function by OPTIMIZE-EXPRESSION and OPTIMIZE-EXPRESSION-1 is
inhibited.
I'm not sure if this says what it intends to say. The way I read it,
a user-defined function will only be optimized if it is also declared
INLINE. This is because user-defined functions are NOTINLINE by
default. Or is there a difference between functions explicitly declared
NOTINLINE and those whose INLINEness is allowed to default? If so, then
I suggest we give a name to this so that users can make such cases
explicit. However, this is the first time such a need has come up, and
I don't really care for it.
barmar