Re: [Gcl-devel] Re: compiler changes

[Camm Maguire]

Greetings!

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

> Camm Maguire wrote:
> 
> > This should be fixed now as well.  I'm getting no failures on misc or
> > the random tester.  Your feedback/testing is always most useful!
> 
> I'm not seeing any failures in the random tester.  I'm seeing lots
> of warnings, however.
> 
> I removed the -Wall from compiler::*cc* to suppress the warnings.
> Most go away, except for an occasional "warning: assignment makes
> integer from pointer without a cast".  I've added a couple of
> test cases to misc.lsp that do this.  It looks like all the dead
> code isn't being removed.
> 

OK, I've fixed the latter, but not yet the former.  Will try to commit
the changes tonight, so hold off a bit.  The former results from GCL's
current failure to remove unused variables in certain cases from the C
output, and I suppose is a lower priority for now.

> 
> > Also, have implemented propagation and inlining for ash.
> 
> Those two tests happen to involve ASH, so this may be related.
> 

Actually something else, but...

> 
> > Also need some separate mechanism by which to
> > progagate mod type information.
> 
> I don't understand -- do you mean the lisp MOD types?  Those
> are just integer subranges.
> 

I'm just beginning to add type propagators that do not pertain to
functions which are simply monotonic in their arguments.  The other
common case is a periodic behavior, e.g. the second result in floor,
the result of mod, etc.  Would be nice to centralize to the extent
possible. 

My question for you right now is -- is it permissible for an
implementation to limit the output of length, position, etc to some
subset of fixnum, e.g. (integer 0 #.(ash most-positive-fixnum -2))?
This allows for many automatic simplifications, of course.

> 
> > Lastly, there is one known outstanding issue remaining at present,
> > (let ((y x)) (and (si::fixnump x) (bar x))) where bar is proclaimed
> > as
> > taking an integer arg with declare y as fixnum.  I need to either
> > type-and within a progn and type-or across an if, or rebind vars
> > within each branch of the if.
> 
> Ah, you mean reverse propagation of type information?
> 
> On branches of an IF, you might try introducing LOCALLY declarations
> (if you handle those).

I think we still need some work in the local declaration department.
Don't even think your function-local optimization declarations are
taking effect yet, but not completely sure here.  But this is the
right idea -- to wrap a let of some form around the if branches.
Luckily, everything in GCL's compiler already boils down to 'if.

Take care,

> 
>       Paul
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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