[cmucl-help] Re: Another stumper compilation diagnostic
One of the goals is to minimize the number of complaints issue by cmucl when loading and compiling. In this I have made some progress as the compilation process that once made 9,000+ notes now outputs only some 1,200 squawks. I hope that within a month or two that I'll have a beta ready; I'll make an announcement here and so the adventuresome may take a crack at any remaining compilation objections. On Sep 25, 2008, at 1:18 PM, Raymond Toy wrote: Madhu wrote: Sorry. Actually I was able to reproduce this under (optimize (speed 3) (space 0)) settings. The MOD and REM come from NTHCDR in list.lisp. Here is a reduced test case: * (defun f (x) (declare (optimize (speed 3)(space 0))) (append (nthcdr 1 x) (nthcdr 1 x))) * (compile 'f) I can't explain it from looking at srctran.lisp's deftransform for nthcdr. My guess. nthcdr is declared maybe-inline. Since speed > space (or maybe space = 0 or something like that), nthcdr is inlined. And that happens before the deftransform for nthcdr is ever gets a chance. Easy enough to put an inhibit-warnings in the offending part of nthcdr. Not sure if we really want to. Or just don't compile the code with speed 3 and space 0. I've never really noticed much speed up with speed 3 on code that manipulates lists. But I don't manipulates lists that much. Ray
[cmucl-help] Re: Another stumper compilation diagnostic
Madhu wrote: > Sorry. Actually I was able to reproduce this under > >(optimize (speed 3) (space 0)) > > settings. The MOD and REM come from NTHCDR in list.lisp. > > > Here is a reduced test case: > > * (defun f (x) (declare (optimize (speed 3)(space 0))) >(append (nthcdr 1 x) (nthcdr 1 x))) > > * (compile 'f) > > I can't explain it from looking at srctran.lisp's deftransform for > nthcdr. My guess. nthcdr is declared maybe-inline. Since speed > space (or maybe space = 0 or something like that), nthcdr is inlined. And that happens before the deftransform for nthcdr is ever gets a chance. Easy enough to put an inhibit-warnings in the offending part of nthcdr. Not sure if we really want to. Or just don't compile the code with speed 3 and space 0. I've never really noticed much speed up with speed 3 on code that manipulates lists. But I don't manipulates lists that much. Ray
[cmucl-help] Re: Another stumper compilation diagnostic
* Madhu <[EMAIL PROTECTED]> : Wrote on Thu, 25 Sep 2008 18:13:43 +0530: | * Steven Edwards <[EMAIL PROTECTED]> : | Wrote on Wed, 24 Sep 2008 14:08:09 -0400: | | | ; (SIXTH MY-TM-LIST) | | ; --> NTH CAR NTHCDR BLOCK FLET TYPECASE LET COND IF COND IF PROGN DO | | BLOCK LET | | ; --> TAGBODY RETURN-FROM PROGN LISP::FAST-NTHCDR | | ; ==> | | ; (MOD LISP::N LISP::I) | | ; Note: Deleting unused function | | ; MOD | | Weird, eh? | | Indeed. I cannot replicate this. Wild Guess: Perhaps you have | redefined SIXTH in your environment and that uses MOD, REM ? Sorry. Actually I was able to reproduce this under (optimize (speed 3) (space 0)) settings. The MOD and REM come from NTHCDR in list.lisp. Here is a reduced test case: * (defun f (x) (declare (optimize (speed 3)(space 0))) (append (nthcdr 1 x) (nthcdr 1 x))) * (compile 'f) I can't explain it from looking at srctran.lisp's deftransform for nthcdr. -- Madhu
[cmucl-help] Re: Another stumper compilation diagnostic
* Steven Edwards <[EMAIL PROTECTED]> : Wrote on Wed, 24 Sep 2008 14:08:09 -0400: | The source (most of it, anyway): | | ; (SIXTH MY-TM-LIST) | ; --> NTH CAR NTHCDR BLOCK FLET TYPECASE LET COND IF COND IF PROGN DO | BLOCK LET | ; --> TAGBODY RETURN-FROM PROGN LISP::FAST-NTHCDR | ; ==> | ; (MOD LISP::N LISP::I) | ; Note: Deleting unused function | ; MOD ... | | Weird, eh? Indeed. I cannot replicate this. Wild Guess: Perhaps you have redefined SIXTH in your environment and that uses MOD, REM ? It is likely that there are bugs in the CMUCL compiler, and it would be useful to isolate a test case, if you are encountering them! Changing the code to eliminate the bug is no fun! The typical braindead way to isolate the test case is to to put the offending code in a separate file in a new package and keep compiling that , remove all calls to functions not in this package or replace them with stubs; and keep hacking at it by chopping extra stuff off until it boils down to a smaller reproducible standalone testcase. This does take some precious time but is usually rewarding if the bug is present, or if it helps identify mistakes in the code -- Madhu :)
