Re: thoughts on peval

[Andy Wingo]

Hi,

On Wed 21 Sep 2011 11:31, address@hidden (Ludovic Courtès) writes:

> Well, top-level procedures aren’t inlined, right?
>
> scheme@(language tree-il optimize)> (define til (cut compile <> #:to 
> 'tree-il))
> scheme@(language tree-il optimize)> (peval (til '(begin (define (foo x) x) 
> (define (bar x) (foo x)) (bar 2))))
> $2 = #<tree-il (begin (define foo (lambda ((name . foo)) (lambda-case (((x) 
> #f #f #f () (#{x 16303}#)) (lexical x #{x 16303}#))))) (define bar (lambda 
> ((name . bar)) (lambda-case (((x) #f #f #f () (#{x 16301}#)) (apply (toplevel 
> foo) (lexical x #{x 16301}#)))))) (apply (toplevel bar) (const 2)))>
>
> So there must be something else going on?

I mean top-level definitions in a file, not in a REPL.  In the REPL they
are compiled separately, whereas for a file, all the toplevel
expressions and definitions are compiled together in one <sequence>,
which currenyly allows them to be inlined (though, see below...)

>> Also, I think that peval is probably inlining too much, at least by
>> default.  By the time that code hits peval, all definitions in a file
>> are in one big <sequence>.  Peval assumes those definitions are static,
>> but that has not historically been the case.  At least by default, we
>> should only inline statically-bound definitions.
>
> This is not the case AFAICT–i.e., top-level definitions are *not*
> eligible for inlining (this is a todo in optimize.scm and in my original
> post.)

Ah, I see that now.  I assumed the local-toplevel-env was being used for
this purpose.  My mistake.

> I was well aware of the risk of excessive inlining, but I thought that
> this and the two other conditions to abort inlining would mitigate the
> problem (the two other conditions being: any static args, and no
> recursive calls in the residual code.)

Well, add a (($ <module-ref>) app) clause to that (match proc ...)
block, and trace what it's doing.  It's pretty crazy :)

Cheers,

Andy
-- 
http://wingolog.org/