Re: [Gcl-devel] Control flow bug involving tagbody, return-from, unwind protect

[Camm Maguire]

Greetings, and thanks as always!  Keep 'em comin!

This was actually not a control flow bug, which I think would have
appeared quite sooner in your tests.  It is rather an error in the
register/volatile detection code of the compiler, combined with an
absence of the traditional gcc warning which alerts me to register
variables 'being clobbered' by longjumps.  Don't know why the latter
isn't there, but as for the former:

Index: gcl_cmplam.lsp
===================================================================
RCS file: /cvsroot/gcl/gcl/cmpnew/gcl_cmplam.lsp,v
retrieving revision 1.8
diff -u -r1.8 gcl_cmplam.lsp
--- gcl_cmplam.lsp      28 Dec 2004 22:24:18 -0000      1.8
+++ gcl_cmplam.lsp      31 Dec 2004 21:36:54 -0000
@@ -354,7 +353,11 @@
         (add-info aux-info (cadr body))
         (setq body (list 'let* aux-info aux-vars aux-inits body))
        (or (eql setjmps *setjmps*) (setf (info-volatile aux-info) t)))
-  
+
+  ;;FIXME -- is above for aux needed too?
+  (when (or optionals keywords)
+    (or (eql setjmps *setjmps*) (setf (info-volatile info) t)))
+
   (setq body (fix-down-args requireds body block-name))
   (setq lambda-list
        (list requireds optionals rest key-flag keywords allow-other-keys))
 

I haven't yet committed this as unfortunately my tree has diverged
somewhat from CVS over the past few days, and I'm still trying to make
up my mind what to do.  The currently committed type-propagation code
adds an additional "half-pass" of my own devising on each binding form
to detect when declarations can be inserted.  This is rather wasteful,
as pass1 already produces much of the same information, and in some
ways succeeds in propagation (e.g.  arguments which are let forms)
where my own code does not yet.  So now I've reworked things to do an
extra pass1 on each let and extract the information I need therefrom.
This slows down compilation by a surprising margin, so I'm not ready
to commit yet.  It also has exacerbated an existing weakness where
'init-forms' placed in the data file can be redundant, now
embarrassingly so.  Am hoping that clearing up the latter might clear
up the former, as with this modular design I can attempt to not only
autodeclare when bindings are unchanged, but to capture the type of
the change and still declare where possible.  Intervening if branches
need to push predicate like forms bearing type information to some
stack accessible by c1setq.  The devil as always is in the non-local
exit forms.

I've also done quite a bit of aref optimization, and some work
reducing the number of 'unused variable' gcc warnings. My general
direction with this type stuff was to automate basically all fixnum
declarations involving sequence indicies, and loop counters where
possible.  Now that I'm thinking about it, though, sequence
indirection via boxed fixnums is not particularly expensive -- I'd
wager not noticeable.  Rather its just the arithmetic, and making sure
boxing doesn't prevent inlining, that appear to count.  I was hoping
that I might be able to optimize all integer arithmetic in the same
progn where the binding is used as a sequence index.

Similarly, I'm wondering about dynamic extent savings.  Does the GC
overhead cost more, or the function call to cons?  There is a lot of
inlining potential remaining for the sequence functions, and it would
be nice while we're at it to notice when some generated list only
passed to member et.al. can be auto-declared dynamic extent, but I'm
not sure how important this might be.  

So as we can see, I'm in the middle of a spate of compiler work,
which, while not necessarily the highest priority, has nevertheless
begun, and needs to be concluded before I move on to something else
lest I forget everything I've learned so far.  So it would be nice to
get some feedback on which compiler features are important to people. 

As to your other misc test, it passes in my not-yet-committed tree,
but I'll save extracting the patch snippet until I can consolidate
everything.  How are we doing on these random-tester issues, btw, vis
a vis the 'competition/?

Take care,


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

> The random tester found a bug involving a fairly complicated
> tangle of control flow.  See mind.518:
> 
> (deftest misc.518
>    (funcall
>     (compile nil '(lambda ()
>                  (declare (optimize (compilation-speed 0) (safety 1)
>                                     (debug 1) (space 0) (speed 3)))
>                  (flet ((%f10 (&optional (f10-1 0) (f10-2 0) &key)
>                               (progn
>                                 (tagbody
>                                  (decf f10-2)
>                                  (return-from %f10
>                                    (complex (unwind-protect (go tag7))
>                                             0))
>                                  tag7)
>                                 f10-2)))
>                    (if (evenp (%f10 0 0)) 0 2140390)))))
>    2140390)
> 
> 
>       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