Re: [Gcl-devel] Re: subtypep issues

[Camm Maguire]

Greetings!

"Paul F. Dietz" <address@hidden> writes:

> Camm Maguire wrote:
> 
> > Yes, it does seem as a construct to aid in array compilation
> > optimization.  The point to me is that I don't see the overwhelming
> > benefit given the definition, though there may be some.  The big issue
> > in our array optimization is to be able to know the element type, rank
> > and sizes to calculate references quickly.  This logic does not
> > depend on displacement as far as I can see, nor even if a fill pointer
> > exists as we use the same slot for the length whether or not it is an
> > adjustable fill pointer.  We don't inline adjust-array, though I
> > suppose we could.
> 
> The benefit is that for a simple array, you can pull out the pointer
> to the contents and (if you know the non-lowest order dimensions)
> you can compile accesses inline as the equivalent C array access.
> 
> If the array is not simple, you must assume that it may have
> its displacement status modified or its dimensions adjusted any time
> you call some possibly redefinable function.
> 

Thanks, this was congruent with my thoughts too.  We store the
dimensions/length parameters in the C structure, and so can read it at
array reference time in C rather than from the type definition at
compile time, so modifications thereto are not a problem, or so it
seems.  Likewise modifications in the displacement status -- this to
me appears useful in loop unrolling where one can be sure the pointers
aren't aliased.  We might be able to make use of this in the future,
but right now we rely on gcc to do loop unrolling if any, which in the
case of function calls in the loop, it won't.  I suppose there might
be some gcc special attribute declaration which GCL could stick in for
simple-arrays, but this appears a minor improvement which we can
tackle in the future if desired. 

So my understanding is that one can still compile C array references
in this case when the type is only known as (array el-tp ...), which
is what we do at present.

> 
> > To this end, the following tests may need adjustment:
> > +SIMPLE-STRING-P.4
> > +SIMPLE-STRING-P.7
> 
> I agree those are bad, and will be removed. But...
> 
> > +SIMPLE-VECTOR-P.10
> > +SIMPLE-VECTOR-P.11
> > +SIMPLE-VECTOR-P.12
> > +SIMPLE-VECTOR-P.7
> > +SIMPLE-VECTOR-P.8
> 
> ... these are good tests, for the reason Christophe explained.
> 

OK, and thanks to Christophe for the clarification of the meaning of
the spec -- sometimes I wish they'd avoid trying to explain everything
in English and just provide code equivalents.  

Request for a test:

(defun foo nil nil)
(defun bar nil t)
(subtypep '(satisfies foo) '(satisfies bar))
(subtypep '(satisfies bar) '(satisfies foo))

and apologies if this is in there somewhere I can't see.  I'm fixing
our nil t to nil nil in my next upload.

When running

(mapcar 'load (remove-if (lambda (x) (search "random" (namestring x)))
(directory "*type*p")))
(rt:do-tests)

I see now

32 out of 760 total tests failed:

among the remaining failures of which is

FLOAT-CPL.4

I've temporarily removed the #+gcl #-gcl macros in
class-precedence-lists.lsp and see the following behavior:

>(load "class-precedence-lists.lsp")

>(CL-TEST::CLASS-PRECEDENCE-LIST-FOO 1.0)

(FLOAT REAL NUMBER T)

>(CL-TEST::CLASS-PRECEDENCE-LIST-FOO 1.0)

(FLOAT REAL NUMBER T)

>(CL-TEST::CLASS-PRECEDENCE-LIST-FOO 1.0)

(FLOAT REAL NUMBER T)

>(CL-TEST::CLASS-PRECEDENCE-LIST-FOO 1.0)

NIL

>

Is there anything you know in the test suite, possibly with other
#+gcl macros, which can describe what is going on here?

Take care,


>       Paul
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah