Re: Type propagation (was Re: [Gcl-devel] New random tester failures)

[Camm Maguire]

Greetings!

OK, take two is committed.  Preliminary suport for ranged types and
their propagation, as well as attempts to recursively determine the
return types of functions when possible from the types of their
arguments. 1+ and 1- are redirected via compiler macros to + and - to
get a bit more leverage here.  Might want to look at the results of
(declare ((integer 0 100) x y)) (+ x y (+ (1+ y) (- 3 x)) 123)

There is still more to be done.  lambda-list variables if constant can
have their types inferred by their use as arguments to proclaimed
functions, though not reliably via the types of initialization forms
in analogy with the lets.  flet and labels definitions can
reciprocally share type information with the bindings used in their
invocations.  And, perhaps most impactfully of all, we have to support
(at least) &optional ftype declarations and incorporate these.  For
example, right now aref is proclaimed ((t *) t) -- not quite sure how
one can indicate that the indefinite number of secondary arguments
have type fixnum without explicitly listing them up to the max rank.
Finally, I'd also like to resolve the following chicken and egg
problem:

(declare ((integer 0 100) x y) (+ x y (let ((z y)) (+ z z)) y)

The let gets bound to a gensym in the compiler macro expansion of + --
attempting to deduce the return type of (+ z z) for this binding would
be logical, but we haven't yet declared z untill we recurse to the
inner scope.  

Anyway, please hammer away, and let me know of errors and things which
aren't optimized but should be.  I always have less time than I'd like
and have done this a bit quickly.

Another thing we need to decide is if there is any benefit to char and
short C variables.  I'm inclined to think not, but have the opposite
opinion on unsigned fixnum and long long.

Oh, yeah, and anyone who things this is neat can feel fre to say so! :-)

Take care,

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

> Camm Maguire wrote:
> 
> > Would appreciate comments as always.  Please note this is still a work
> > in progress.
> 
> I looked at what gets produced for functions like this one:
> 
> (declaim (optimize (speed 3) (safety 0) (debug 0) (compilation-speed 0) 
> (space 0)))
> 
> (defun foo (x y)
>    (declare (type (integer 0 100) x y))
>    (+ x y 123))
> 
> It doesn't unbox the arithmetic here, which tells me it isn't doing
> the best job of type progation on + (it does unbox and do the arithmetic
> inline if the intermediate and final results are asserted to be fixnums
> with THE).  This operator should be such that if E1 and E2 have types
> (INTEGER LO1 HI1) and (INTEGER LO2 HI2), then (+ E1 E2) has type
> (INTEGER LO3 HI3), where LO3 = (+ LO1 LO2) and HI3 = (+ HI1 HI2).
> 
> This kind of fine grained type propagation is essential in many
> cases, since just defining things to be fixnums makes most arithmetic
> operations overflow.
> 
>       Paul
> 
> 
> 
> 

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