gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] New random tester failures


From: Camm Maguire
Subject: Re: [Gcl-devel] New random tester failures
Date: 10 Dec 2004 19:43:34 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!

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

> Camm Maguire wrote:
> > Greetings, and thanks again as always, Paul!
> > I have a fix for this, as yet uncommitted.  But I realize as I chase
> > these down that I need very frequently to rebind arguments in a let*
> > using gensymmed temporaries, and this has reminded me of a
> > longstanding performance problem with this I'd like to fix.  In brief,
> > doing this destroys any type information that may exist for the
> > rebound variable via declaration or proclamation.
> > I have plan A and plan B, and would like to solicit your opinion:
> > A) When the compiler expands macros, or funcalls compiler macro
> > functions, detect whether new bindings are introduced, and if so,
> > recursively macroexpand the form, determine whether the binding is
> > changed in the body of the new let, and if not, add a declaration read
> > from a stack when appropriate at the head of the let.  Advantage --
> > centralized -- disadvantage -- could be slightly tricky.
> 
> 
> Isn't this just a special case of the more general procedure of adding
> declarations for locals that are not later assigned?  There's no need for
> those locals to have been introduced by a macro.
> 

Indeed.  OK, took a stab at a more general solution in CVS now.  There
is a quite loquacious compiler note for now describing the reasoning
whereby the compiler inserts type declarations into let and let*
bodies, and bodies following lambda expressions, whether the bindings
are introduced by macros or not.  This can be expanded upon further,
primarily through careful proclamation of our existing functions.  >2k
random tester iterations pass, and the same results on self-compile,
misc, and ansi-tests, but a performance gain of some 8% in the latter,
25% in the gc component.

Haven't fixed the incf/decf yet -- hope to get to that shortly.  But
at least I'm not plagued by reticence in introducing more macros
producing bindings of gensymmed variables.

Would appreciate comments as always.  Please note this is still a work
in progress.

Take care,

> 
> > B) Push declarations onto the environment passed to macroexpand, and
> > rewrite each relevant macro (mostly setf expanders and compiler
> > macros) to insert the declarations where appropriate.
> > I'm leaning toward A, but am quite open minded.
> 
> Either one sounds ok, although the first could be made more general.
> 
> > Remember your aluding to an Allegro proposal by Duane Rettig (?) when
> > we discussed this before, but never could find this.
> 
> It's in the ACL 7.0 release notes.
> 
> http://www.franz.com/support/documentation/7.0/doc/environments.htm
> 
>       Paul
> 
> 
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]