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
>