Re: issue DEFINE-OPTIMIZER, version 6

[Dan L. Pierson <pierson@mist.encore.com>]

    Date: Fri, 24 Mar 89 11:22 EST
    From: Barry Margolin <barmar@Think.COM>
    
    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.
    
Part of the point is if a user defines such an optimizer _and_ the
implementation causes user optimizers to override built-in optimizers,
the user might unknowingly override a built-in optimizer that did all
of the above and in addition converted multiplication by small
constant values to inline shifts and adds.  In general, defining an
optimizer for code you didn't right (especially built-in code) is
risking a chance that you have accidentally defined a pesimizer
instead.

Of course, you can and should should always test to see that such
optimizers really improve performance by your favorite metric and
don't break the function being optimized (and repeat such tests with
every new version of the implementation).  This is a lot of work, and
IMHO, the repeated testing part of it is all too likely to be
neglected.

We're not saying that you should *never* write an optimizer for code
you don't maintain.  We are saying that you should think very
carefully about it and we are giving implementations maximum freedom
by saying that defining optimizers for CLtL forms (really for any
implementation forms) are undefined.