[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: DEFINE-OPTIMIZER
- To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Subject: Re: Issue: DEFINE-OPTIMIZER
- From: David N Gray <Gray@DSG.csc.ti.com>
- Date: Wed, 28 Sep 88 15:43:01 CDT
- Cc: CL-Compiler@SAIL.Stanford.EDU
- In-reply-to: Msg of Wed, 28 Sep 88 15:31 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Sender: GRAY@Kelvin.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
> 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
> 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.