Re: peval update

[Ludovic Courtès]

Hi Andy!

(As you can see I’m lagging behind and notice guile-commits before
guile-devel.  :-))

Andy Wingo <address@hidden> skribis:

> Firstly, it now works on all of Guile's code -- all of its constructs.

Cool!

> Also, peval is now strictly O(N), because it has "effort counters", as
> in Waddell and Dybvig's paper.  Each call site in the source program is
> allocated some amount of "effort", and if that effort is all used up,
> peval aborts back to the inlining attempt and residualizes the call.  N
> call sites * constant effort = O(N).

Excellent!  I noticed that, as a side-effect (I suppose), it fixes
infinite recursion while trying to inline a function application with
static arguments but whose result does not depend solely on these
arguments (the example in commit
21524430e9d821014d6c0efbe4df74c12179c072).

It also removes the main reason for not having peval inline module-local
top-level bindings (the previous approach was way too aggressive.)  Have
you thought about it?

> Another thing to fix is that peval doesn't always spend its effort
> wisely.  It can visit operands more than once, which is
> counter-productive.  It should memoize residual code emitted, as Waddell
> and Dybvig do.  If it did this residualization at time of use instead of
> time of definition, that would turn the algorithm into being
> demand-driven, allowing more accurate code size computations.  It would
> also allow context-specific processing of operands to calls, like in
> test context or effect context.

Hmm, interesting.

> Demand-driven processing would also make `letrec' optimization more
> effective.  Currently `letrec'-bound bindings are not mutually inlined.

When there are no static arguments, right?

> You can see the result of this in psyntax-pp.scm: things that are
> inlined in the body are not inlined in the letrec-bound helpers.

OK.

Thanks for turning a nice hack into a practical optimizer!

Ludo’.