[gambit-list] Guile's new compiler

Bradley Lucier lucier at math.purdue.edu
Fri Nov 6 14:51:03 EST 2015


On 11/06/2015 11:54 AM, Marc Feeley wrote:
> One issue with your example is that ##string-length (and many other ## primitives) were not being constant folded.  That is now fixed.
>
> Another issue is that for the (let loop ((i 0)) …) there is no loop peeling occurring.  Note that the let loop expands to a (letrec ((loop (lambda (i) …))) (loop 0)) .  I noticed that the beta-reducer was not constant propagating the value of i in (let ((i 0)) …) after the first inlining of the function.  So I added a beta-reduction of the let.
>
> But there is another issue…  The inliner will limit the expansion of the code to some factor of the size of the call site.  Here the call site which starts the loop is (loop 0), a tiny call of size 3 (the size is the number of parse-tree nodes).  Increasing the inlining-limit at the top of the file does not help because the body of the loop function is expanded before the call site is considered for inlining, so the body of the loop function is bigger and doesn’t get inlined.  So a workaround is to rewrite the loop so that it is a separate function, and then attach a high inlining limit to the call.  An alternative is to have a high inlining limit for the (let loop …) and a low inlining limit for the loop body.  For example:
>

Wow, what progress in such a short time!

Here's an idea:

In the example, if the body of lambda is expanded into the call (loop 
0), then the original lambda can be removed!  So this doesn't increase 
the total size of the code at all.  Maybe you can have logic that says: 
  If a the inlinining limit is k * 100, and a lambda has no more than k 
possible call sites, then expand that lambda into the call sites and 
eliminate the code for the original lambda.

If that idea isn't precisely correct then maybe it's something one could 
start with to get something that works.

Brad



More information about the Gambit-list mailing list