From: <bdo...@la...> - 2006-10-30 16:51:50
|
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) *compile-object* :path path))) (when for-value-p (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 (in-package :cl-user) (defun foo (x) (list x)) (defun bar (x) (1+ (foo x))) EOF expect_failed_compile $tmpfilename 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. :) -bcd |