[Sbcl-commits] CVS: sbcl version.lisp-expr,1.4409,1.4410

Update of /cvsroot/sbcl/sbcl
In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv29774
Modified Files:
version.lisp-expr
Log Message:
1.0.27.43: constant coalescing agreement fixes
Constant coalescing decisions, legitimately differing between different
hosts, can if not very careful propagate into the target, often through
vop-parse structures. Be explicit in which constants can be shared and
which shouldn't.
5 messages follow:
constant coalescing KLUDGE, part 1 [(any)]
The constant initforms for the vop-parse structure are evaluated on the
host; therefore, their coalescing is at the host's discretion. This
wouldn't matter except that (why?) vop-parse structures get dumped
at each vop definition. Make the coalescedness explicit.
constant coalescing KLUDGE, part 2: [(fixnumize n)]
The static function template for at least LENGTH (in subprim.lisp)
contains two instances of (FIXNUMIZE 2), which are coaelesced
differently on different host lisps. We can KLUDGE around this problem
(and gain a millimetric amount of efficiency, too!) by evaluating the
FIXNUMIZE calls at expansion time.
remove confusing code structure sharing from DEF-MOVE-IF
I can't actually see exactly where the code structure sharing happens
nor why it causes xc fasl contents to differ between hosts, but since
it makes the code clearer to rewrite the macro...
fix two separate issues in compiler/globaldb
One is a hash-table traversal issue; the other is coalescing of
constants. I *think* what's going on in the latter case is that there
are two separate ways that shared constants can happen. One is in the
dumping of objects which are EQUAL, where the compiler can dump a
reference to a previous object instead; the other is the dumping of a
single object with circularities, where a nil is dumped along with a
later instruction to backpatch the circularity in. We need to ensure a
deterministic cold-init-form, so that means we need to control the
coalescing in the _host_ compiler (because the cold-init-form is
generated from introspection), but of course we can't, so we COPY-TREE
instead, which will allow the xc to coalesce and will prevent the form
as compiled from sharing structure.
Static function template vop macro has a common subexpression, factored
out as new-ebp-ea.
Index: version.lisp-expr
===================================================================
RCS file: /cvsroot/sbcl/sbcl/version.lisp-expr,v
retrieving revision 1.4409
retrieving revision 1.4410
diff -u -d -r1.4409 -r1.4410
--- version.lisp-expr 24 Apr 2009 15:08:28 -0000 1.4409
+++ version.lisp-expr 24 Apr 2009 15:37:46 -0000 1.4410
@@ -17,4 +17,4 @@
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.27.42"
+"1.0.27.43"

Thread view

Update of /cvsroot/sbcl/sbcl
In directory fdv4jf1.ch3.sourceforge.com:/tmp/cvs-serv29774
Modified Files:
version.lisp-expr
Log Message:
1.0.27.43: constant coalescing agreement fixes
Constant coalescing decisions, legitimately differing between different
hosts, can if not very careful propagate into the target, often through
vop-parse structures. Be explicit in which constants can be shared and
which shouldn't.
5 messages follow:
constant coalescing KLUDGE, part 1 [(any)]
The constant initforms for the vop-parse structure are evaluated on the
host; therefore, their coalescing is at the host's discretion. This
wouldn't matter except that (why?) vop-parse structures get dumped
at each vop definition. Make the coalescedness explicit.
constant coalescing KLUDGE, part 2: [(fixnumize n)]
The static function template for at least LENGTH (in subprim.lisp)
contains two instances of (FIXNUMIZE 2), which are coaelesced
differently on different host lisps. We can KLUDGE around this problem
(and gain a millimetric amount of efficiency, too!) by evaluating the
FIXNUMIZE calls at expansion time.
remove confusing code structure sharing from DEF-MOVE-IF
I can't actually see exactly where the code structure sharing happens
nor why it causes xc fasl contents to differ between hosts, but since
it makes the code clearer to rewrite the macro...
fix two separate issues in compiler/globaldb
One is a hash-table traversal issue; the other is coalescing of
constants. I *think* what's going on in the latter case is that there
are two separate ways that shared constants can happen. One is in the
dumping of objects which are EQUAL, where the compiler can dump a
reference to a previous object instead; the other is the dumping of a
single object with circularities, where a nil is dumped along with a
later instruction to backpatch the circularity in. We need to ensure a
deterministic cold-init-form, so that means we need to control the
coalescing in the _host_ compiler (because the cold-init-form is
generated from introspection), but of course we can't, so we COPY-TREE
instead, which will allow the xc to coalesce and will prevent the form
as compiled from sharing structure.
Static function template vop macro has a common subexpression, factored
out as new-ebp-ea.
Index: version.lisp-expr
===================================================================
RCS file: /cvsroot/sbcl/sbcl/version.lisp-expr,v
retrieving revision 1.4409
retrieving revision 1.4410
diff -u -d -r1.4409 -r1.4410
--- version.lisp-expr 24 Apr 2009 15:08:28 -0000 1.4409
+++ version.lisp-expr 24 Apr 2009 15:37:46 -0000 1.4410
@@ -17,4 +17,4 @@
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"1.0.27.42"
+"1.0.27.43"