[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Date: Tuesday, 10 May 1988 22:20-EDT
From: Jon L White <edsel!jonl at labrea.stanford.edu>
To: ELIOT at cs.umass.edu
cc: common-lisp at sail.stanford.edu
re: Knowing the FTYPE of sqrt does not allow a compiler to substitute 2.23 for
(sqrt 5). You might redefine SQRT as SIN without violating the FTYPE.
Right. So your intention for "constant function" really was more along the
line of "constant foldable" (or "reducible"), just as I guessed in my first
I think there are *three* kinds of compiler optimizations we're
talking about, not the two that have been bandied about. Given the function
(defun bar (x) (+ x 1))
the form (foo (bar 7) (bar 7)) might be compiled in several ways:
* INLINE compilation would be (foo (+ 7 1) (+ 7 1)). Yes, a later
constant folding stage would do more. But *this* is what INLINE means.
* CONSTANT FOLDING, as JonL point out, would be (foo 8 8). Note that
in the general case this potentially requires executing random user
function definitions from within the compiler.
* But REDUCIBLE is what Barmar said; avoid re-executing the function
at run time if the arguments are the same (yes, this is the same as
common subexp elim). In other words, a source-to-source transform
might yield (let ((gensym (bar 7))) (foo gensym gensym)). Note that
this does *not* require executing user code. I'm sure that this is
what Multics PL/1 does (though my old 1976 Multics PL/I manual
doesn't mention it).
These transforms obviously have different effects on code size and
runtime behavior (particularly in a non-functional language).
I agree with the comment that we need to provide the compiler with
information about *the function* rather than how we think the compiler
should *treat* the function at compile time.
-- Richard Soley