On Mon, Oct 30, 2006 at 10:06:25AM -0600, Nathan Froyd wrote:
> On Thu, Oct 26, 2006 at 11:01:44AM -0500, Brian Downing wrote:
> > The questions I was intending to ask about the difference in compile
> > output were basically "why," and "which one is better" - i.e. should I
> > "fix" compiling interpreted functions to look like what you get when
> > you type the same function at the REPL?
> I think that compiling interpreted functions does the right thing and
> that functions defined at the REPL via DEFUN should be tweaked (via
> %SIMPLE-EVAL) to look like what you get when you compile an interpreted
> function. Smaller code, less garbage in the disassembly.
I also found this in the fopcompiler:
;; We wrap the real lambda inside another one to ensure
;; that the compiler doesn't e.g. let convert it, thinking
;; that there are no external references.
(let* ((handle (%compile `(lambda () ,form)
(sb!fasl::dump-push handle *compile-object*)
;; And then call the wrapper function when loading the FASL
(sb!fasl::dump-fop 'sb!fasl::fop-funcall *compile-object*)
(sb!fasl::dump-byte 0 *compile-object*)))
...which results in a similar effect in fopcompiled functions.
I tried just dumping the raw function (a simple what-if scenario, I
didn't really expect it would work) and saw a 700k reduction in core
size (amd64), and of course smaller (and presumably faster-loading)
fasl files. It managed to get through the build and build all contribs.
Unfortunately, this compiler test case failed:
# This should fail, as type inference should show that the call to FOO
# will return something of the wrong type.
cat > $tmpfilename <<EOF
(defun foo (x) (list x))
(defun bar (x) (1+ (foo x)))
That aside, I think it would be nice if we didn't have to wrap everything
in extraneous lambdas - the reduction in core file and fasl size sure
is nice. It seems like this wrapping shouldn't be neccessary - after
all, the cross-compiled functions don't appear to have it done to them -
but my current knowledge of the SBCL compiler is at its limits. :)