From: Stelian I. <sio...@cd...> - 2009-08-21 08:25:59
|
Compiling latest clx, I get this: ; compiling file "/home/hechee/lisp/src/clx/manager.lisp" (written 03 NOV 2008 12:58:35 AM): ; compiling (IN-PACKAGE :XLIB) ; compiling (DEFUN WM-NAME ...) ; compiling (DEFSETF WM-NAME ...) ; compiling (DEFUN SET-STRING-PROPERTY ...) ; compiling (DEFUN WM-ICON-NAME ...) ; compiling (DEFSETF WM-ICON-NAME ...) ; compiling (DEFUN WM-CLIENT-MACHINE ...) ; compiling (DEFSETF WM-CLIENT-MACHINE ...) ; compiling (DEFUN GET-WM-CLASS ...) ; compiling (DEFUN SET-WM-CLASS ...) ; file: /home/hechee/lisp/src/clx/manager.lisp ; in: DEFUN SET-WM-CLASS ; (MAP '(VECTOR XLIB:CARD8) #'XLIB:CHAR->CARD8 ; (STRING (OR XLIB::RESOURCE-CLASS ""))) ; --> TRULY-THE SB-KERNEL:%MAP COERCE ; ==> ; (THE (VECTOR XLIB:CARD8) ; (IF (TYPEP SB-C::X '(ARRAY (UNSIGNED-BYTE 8) (*))) SB-C::X ; (REPLACE ; (MAKE-ARRAY (LENGTH SB-C::X) :ELEMENT-TYPE '(UNSIGNED-BYTE 8)) ; SB-C::X))) ; ; caught WARNING: ; Asserted type (VECTOR (UNSIGNED-BYTE 8)) conflicts with derived type ; (VALUES SIMPLE-VECTOR &OPTIONAL). ; See also: ; The SBCL Manual, Node "Handling of Types" ; (MAP '(VECTOR XLIB:CARD8) #'XLIB:CHAR->CARD8 ; (STRING (OR XLIB::RESOURCE-NAME ""))) ; --> TRULY-THE SB-KERNEL:%MAP COERCE ; ==> ; (THE (VECTOR XLIB:CARD8) ; (IF (TYPEP SB-C::X '(ARRAY (UNSIGNED-BYTE 8) (*))) SB-C::X ; (REPLACE ; (MAKE-ARRAY (LENGTH SB-C::X) :ELEMENT-TYPE '(UNSIGNED-BYTE 8)) ; SB-C::X))) ; ; caught WARNING: ; Asserted type (VECTOR (UNSIGNED-BYTE 8)) conflicts with derived type ; (VALUES SIMPLE-VECTOR &OPTIONAL). ; See also: ; The SBCL Manual, Node "Handling of Types" ; compiling (DEFUN WM-COMMAND ...) ; compiling (DEFSETF WM-COMMAND ...) ; compiling (DEFUN SET-WM-COMMAND ...) ; file: /home/hechee/lisp/src/clx/manager.lisp ; in: DEFUN SET-WM-COMMAND ; (MAP '(VECTOR XLIB:CARD8) #'XLIB:CHAR->CARD8 ; (WITH-OUTPUT-TO-STRING (STREAM) ; (WITH-STANDARD-IO-SYNTAX (PRIN1 XLIB::C STREAM)))) ; --> TRULY-THE SB-KERNEL:%MAP COERCE ; ==> ; (THE (VECTOR XLIB:CARD8) ; (IF (TYPEP SB-C::X '(ARRAY (UNSIGNED-BYTE 8) (*))) SB-C::X ; (REPLACE ; (MAKE-ARRAY (LENGTH SB-C::X) :ELEMENT-TYPE '(UNSIGNED-BYTE 8)) ; SB-C::X))) ; ; caught WARNING: ; Asserted type (VECTOR (UNSIGNED-BYTE 8)) conflicts with derived type ; (VALUES SIMPLE-VECTOR &OPTIONAL). ; See also: ; The SBCL Manual, Node "Handling of Types" -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib |
From: Christophe R. <cs...@ca...> - 2009-08-21 10:39:33
|
Stelian Ionescu <sio...@cd...> writes: > ; file: /home/hechee/lisp/src/clx/manager.lisp > ; in: DEFUN SET-WM-CLASS > ; (MAP '(VECTOR XLIB:CARD8) #'XLIB:CHAR->CARD8 > ; (STRING (OR XLIB::RESOURCE-CLASS ""))) > ; --> TRULY-THE SB-KERNEL:%MAP COERCE > ; ==> > ; (THE (VECTOR XLIB:CARD8) > ; (IF (TYPEP SB-C::X '(ARRAY (UNSIGNED-BYTE 8) (*))) SB-C::X > ; (REPLACE > ; (MAKE-ARRAY (LENGTH SB-C::X) :ELEMENT-TYPE '(UNSIGNED-BYTE > 8)) > ; SB-C::X))) > ; > ; caught WARNING: > ; Asserted type (VECTOR (UNSIGNED-BYTE 8)) conflicts with derived type > ; (VALUES SIMPLE-VECTOR &OPTIONAL). > ; See also: > ; The SBCL Manual, Node "Handling of Types" Yuk. A reduced test case: (defun foo (x) (declare (type simple-vector x)) (the (vector (unsigned-byte 8)) (if (typep x '(array (unsigned-byte 8) (*))) x (replace (make-array (length x) :element-type '(unsigned-byte 8)) x)))) That is, the bug is exposed by the COERCE transform but isn't actually caused by the changes in 1.0.30.17. The problem is that the TYPEP check is source transformed into (LET ((#:N-OBJ0 X)) (AND (VECTORP #:N-OBJ0) (DO ((#:DATA[FOO]1 (TRULY-THE VECTOR #:N-OBJ0) (SB-KERNEL:%ARRAY-DATA-VECTOR #:DATA[FOO]1))) ((NOT (SB-KERNEL:ARRAY-HEADER-P #:DATA[FOO]1)) (EQ (SB-KERNEL:%OTHER-POINTER-WIDETAG #:DATA[FOO]1) 142))))) which the compiler is then not smart enough (understandably!) to replace with NIL when it later gets the information that X is a SIMPLE-VECTOR. I think that to bandage this we need type predicates (à la SB-C::DEFINE-TYPE-PREDICATE) for (VECTOR ELTYPE). (SBCL is correctly able to derive everything if instead of (array (unsigned-byte 8) (*)) in FOO above, the type is (simple-array (unsigned-byte 8) (*)). Cheers, Christophe |
From: Christophe R. <cs...@ca...> - 2009-08-23 21:40:14
|
Hi, Stelian Ionescu <sio...@cd...> writes: > ; in: DEFUN SET-WM-CLASS > ; > ; caught WARNING: > ; Asserted type (VECTOR (UNSIGNED-BYTE 8)) conflicts with derived type > ; (VALUES SIMPLE-VECTOR &OPTIONAL). sbcl-1.0.30.51, just merged, should fix this issue. (Please let me know if it doesn't!) I'd like to freeze development for the 1.0.31 release; I'm aware that Paul Khuong has some patches to come, but otherwise please would people test CVS against their favourite applications and libraries, report problems, and committers exercise even more taste than usual when contemplating the changes that they intend to make. I expect to release around the middle of the week. Best, Christophe |
From: Stelian I. <sio...@cd...> - 2009-08-23 22:50:54
|
On Sun, 2009-08-23 at 22:40 +0100, Christophe Rhodes wrote: > Hi, > > Stelian Ionescu <sio...@cd...> writes: > > > ; in: DEFUN SET-WM-CLASS > > ; > > ; caught WARNING: > > ; Asserted type (VECTOR (UNSIGNED-BYTE 8)) conflicts with derived type > > ; (VALUES SIMPLE-VECTOR &OPTIONAL). > > sbcl-1.0.30.51, just merged, should fix this issue. (Please let me know > if it doesn't!) Thanks, it works -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib |
From: Christophe R. <cs...@ca...> - 2009-08-26 21:06:50
|
Christophe Rhodes <cs...@ca...> writes: > I'd like to freeze development for the 1.0.31 release; I'm aware that > Paul Khuong has some patches to come, but otherwise please would people > test CVS against their favourite applications and libraries, report > problems, and committers exercise even more taste than usual when > contemplating the changes that they intend to make. I expect to release > around the middle of the week. I've merged a few more patches (from Paul's queue) to cure outright regressions since 1.0.30. Unless something nasty crops up (please test!) I expect to release tomorrow, or early Friday. Something that I noticed when looking at the xc leak in %unary-truncate: there's something odd about the code generation for inline constants, or possibly the *elsewhere* segment. On x86-64, on my systems, disassembling sb-kernel:%unary-truncate/double-float shows that, after the error trapping code (invalid-arg-count-error, object-not-double-float-error) there are 64 nops before what I think are 4 bytes of zeros for alignment and then two lots of 8 bytes for the double floats. Is there an obvious reason for this? Cheers, Christophe |
From: Paul K. <pk...@gm...> - 2009-08-27 00:24:01
|
On 26-Aug-09, at 5:06 PM, Christophe Rhodes wrote: > Something that I noticed when looking at the xc leak in %unary- > truncate: > there's something odd about the code generation for inline > constants, or > possibly the *elsewhere* segment. On x86-64, on my systems, > disassembling sb-kernel:%unary-truncate/double-float shows that, after > the error trapping code (invalid-arg-count-error, > object-not-double-float-error) there are 64 nops before what I think > are > 4 bytes of zeros for alignment and then two lots of 8 bytes for the > double floats. Is there an obvious reason for this? I should have documented this better. There are two cases here: If we optimize for speed > space: The goal is to make sure data and instructions fall in different cache lines, thus the 64 NOPs. Split L1I and L1D (found in nearly all x86 uarch with caches) don't react well to executing and loading from the same cache line (at least we're not writing to the inline constant pool). Otherwise: IIRC, some uarchs' instruction decoder can suffer from reduced throughput if they look ahead and hit illegal instructions. The 16 bytes of NOPs are there to avoid that scenario. Any padding size would be correct for strict correctness, but I was afraid of performance regression in normal code without that small amount. Paul Khuong |