Re: [Gcl-devel] Re: (random tester) Another compiler side effects bug

[Camm Maguire]

Greetings! 

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

> Camm Maguire wrote:
> > Greetings!
> > Paul I think this is now fixed in 2.6.1 and cvs head.  Please let me
> > know if I've made a silly mistake.
> 
> I'm not sure if you've made a mistake, but the compile time seems
> to have gone up a lot in some cases (it may even be looping).
> 
> Did you use an algorithm that may have bad worst case behavior?
> 

OK, an example showing a notable compile time performance degradation
before vs. after the latest commit would be most helpful.  (You can
still access the cvs as of a certain date with the -D flag).  My guess
is that a trace of compiler::add-info would be illustrative.  If you
can send me a test function, I'll take a look at it.

The compiler builds internal 'info' structures for each compilation
unit, (i.e. a function, a function call, a let body, etc.) -- all I've
done is to make sure that 'function' info is added into the
'call-local' info in (hopefully) all cases.  

These info objects are structures one element of which is a list of
changed variables.  Unique elements in one such list get pushed onto
the parent list in add-info.  When I fixed one of your earlier bugs,
all was well until one tried to compile maxima's nusum.lisp -- as
add-info was using 'append' to merely concatenate the lists, so much
consing was taking place that the gbc almost ground the whole process
to a halt.  I changed add-info to only push unique elements onto the
parent, and all was well.  So you might want to turn on
si::*notify-gbc*. 

(Note: In general, I've tried to stick with what I perceive is the
lisp philosophy of not caring about copies and conses and other gbc
issues when compared with the perils of modifying a list in place and
possibly introducing side-effects in the parent.  Any rules of thumb
regarding safe avoidance of consing are appreciated.)

Then you turned up the multiple-value call pathway, in which the
function info was not being added to the call-local.  I moved the
add-info step to the base of the call-local creation stage
(c1local-fun and c1local-closure) resulting in an (apparent) fix.
What is unusual is that these functions built the call-local
compilation unit with a special global variable *info* which is
apparently never being rebound.  I put a FIXME note into the patch to
figure out why this was implemented with a special here, where in most
other cases one makes a fresh structure or a copy of an existing
structure when building a new unit.  In any case, I made the patch
minimal, preserving this behavior, but have not yet examined the
*info* variable after compilation.  

I also simplified the info addition for the call-global unit,
restoring basically the original behavior.  It turns out that a
modification I made when investigating your first report was
superfluous.   I did discover that one could introduce a loop if one
doesn't ensure that (c1args arg info), which is used to add the
argument info into a 'call-global', is called only once at the top
level of the creation of the call-global compilation unit.

Please let me know especially if 1) any compiles fail to complete, or
2) other instances of the side-effect bug turn up.

Take care,

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

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