Re: [Gcl-devel] New random tester failures

[Camm Maguire]

Greetings!

Interesting -- I had thought we'd hit gcl memory limits far before
gcc.  

In any case, I can't do anything with just this C file.  Need at least
the .h and .data files too, and most prefereably the lisp.  You can
save all these files by

(setq compiler::*keep-gaz* t compiler::*default-c-file* t
compiler::*default-h-file* t compiler::*default-data-file* t
compiler::*fasd-data* nil)

(first keeps the lisp, next three self explanatory, last so a human
can read the data file)

Even with these files, it is not clear what the resolution should be,
and I'd appreciate suggestions.  We should check under 2.6.5 for good
measure first in any case.  I doubt we are so lucky that it is simply
a question of breaking the line in C.  Asusming there is some serious
parenthesis nesting limitations in gcc, probably the easiest is to
break up the form in the compiler macro into parts bound to
intermediary variables.  How to determine this limit is again somewhat
unclear, as the expresion in your file is the "fully optimized" result
the compiler intended to arrive at, and any alteration would represent
some deterioration at runtime, with savings achieved at compile time.
Usually we want to go the other way.

Just to clarify again what these compiler macros are supposed to do,
GCL can optimize certain binary operations quite well in terms of C
primitives, e.g. if the vars are known to be fixnum, for example,

(+ a b) -> V1+V2

but, traditionally

(+ a b c) 

pushed the eval'ed args to the lisp stack and called Lplus.

The compiler macros now write this as

(+ (+ a b) c)

and the optimizer produces V1+V2+V3 when the types are known, etc.

What we have been working on is an algorithm to decide when we rather
need 

(let* ((:g1 a)(:g2 b)(:g3 c)) (+ (+ :g1 :g2) :g3))

(hope we've got it now).

Conditionals go to eg.  (V1 > V2 ?  V1 : V2), hence the nesting
issues.

Take care,

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

> Camm Maguire wrote:
> > Thanks!  OK, a retreat to a yet more conservative position.  What is
> > committed now passed 2k random-tester iterations for me.
> > At some point we need to make use of compiler detection of
> > side-effects in functions.  The hooks are there already.
> 
> I tweaked up the probability of producing large n-ary expressions
> and of setf/setq/incf/decf calls.
> 
> I'm seeing something odd in gcl's compiler.  It's producing C
> files that are causing the C compiler to use very large amounts
> of memory (> 800 MB in some cases), causing my machine to thrash.
> I'll send you an example of such a C file in the next message
> (it's 1.7 MB, so I will gzip it first; I don't have the associated
> lisp.)
> 
> The file contains a function with a huge tree of nested conditional
> expressions.  This must be what is causing the compiler to take
> so long.
> 
>       Paul
> 
> 
> 

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