gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: Ping


From: Camm Maguire
Subject: [Gcl-devel] Re: Ping
Date: 23 Jan 2007 19:51:12 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings!  I have a pretty sizable commit just about ready to go in.
Might be a good idea to copy your working 2.7.0 tree if any.

Basically, I figured out how to get inlining to work from the function
source alone, i.e. without reimplementation in the form of one
compiler macro per function, etc.  In addition to greatly simplifying
compiler maintenance, of course many more functions can now be
automatically inlined, the declaim stuff works, and even apply can
inline its callee, sharing structure of any &rest parameter with the
supplied list.  I've reimplemented all the basic list and sequence
functions in lisp with this in mind, for example providing inlinable
versions of copy-tree, subst, sublis, etc which avoid recursion and
use a :dynamic-extent list stack to do their work.

There is a heuristic for controlling this with *space* by counting
nodes in the expanded form, and hashing negative results for speed --
this needs more work.  We should be able to hash precompiled forms for
the most common functions, but this is a bit dangerous and tricky as
you might suspect.  The compile time is still faster than gcc, but
this is adding some overhead here.

I have many questions to seek your advice upon in this regard -- more
later.  I have a shot at getting this in tomorrow.  Thereafter will be
out on business for two days.  And in Feb., I'll be gone the whole
month. 

Take care,

Robert Boyer <address@hidden> writes:

> Hi.  Got your message about inlining.  Just have little to say on the
> topic.  When to inline is a very deep problem that has been little
> explored as far as I know, and that means little.  The fact that it can
> now be done in GCL 2.7.0, because the sources are kept around, is
> fabulous.
> 
> A first step, it seems to me, is simply to assure that the commands
> 'inline' and 'notinline' really work as ANSI says.  Even that looks
> complicated to me.  See below.
> 
> March would be great time for you to visit, as is anytime.  It is
> Warren's schedule that you we have to consider since he travels.  As a
> general rule, I am here in Austin, and most happy to have you visit!
> 
> Bob
> 
> -------------------------------------------------------------------------------
> 
> >From the ANSI:
> 
> While no conforming implementation is required to perform inline
> expansion of user-defined functions, those implementations that do
> attempt to recognize the following paradigm:
> 
> To define a function f that is not inline by default but for which
> (declare (inline f)) will make f be locally inlined, the proper
> definition sequence is:
> 
>  (declaim (inline f))
>  (defun f ...)
>  (declaim (notinline f))
> 
> The inline proclamation preceding the defun form ensures that the
> compiler has the opportunity (to *??*) save the information necessary
> for inline expansion, and the notinline proclamation following the defun
> form prevents f from being expanded inline everywhere.
> 
> 
> 

-- 
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]