[gambit-list] JavaScript backend

Marc Feeley feeley at iro.umontreal.ca
Tue Jan 12 23:11:33 EST 2016


What is the transformation you have in mind?  It seems to me that for the optimization to operate at the basic block level, the construction of the vector and the indexing would have to be very close to each other, rather unlikely in complex code.

I think the transformation should be done on the ast (in _ptree2.scm).

It would need to take the code

    (let ((v (vector E0 E1 E2 E3)))
      …
        (vector-ref v 1)
      …
        (vector-ref v 2)
      …)

and, after checking that v is not mutated or passed to a function, convert it to

    (let* ((elem0 E0)
           (elem1 E1)
           (elem2 E2)
           (elem3 E3)
           (v (vector elem0 elem1 elem2 elem3)))
      …
        elem1
      …
        elem2
      …)

then the compiler would eliminate the call to vector (a side-effect free primitive) if it sees that v is not referenced anywhere else (this is already optimized by the compiler).

But does this pattern occur with enough frequency to justify the time required implementing the optimization?

I think a more frequent pattern is

    (define (f a b c) … (vector E0 E1 E2 E3))

    (let ((v (f 1 2 3)))
      …
        (vector-ref v 1)
      …
        (vector-ref v 2)
      …)

and that is harder to handle.

Marc

> On Jan 12, 2016, at 10:49 PM, Bradley Lucier <lucier at math.purdue.edu> wrote:
> 
> On 01/12/2016 10:48 PM, Marc Feeley wrote:
>> Deforestation would require a control flow analysis, which is quite a bit more complex than the 40 line optimization I added.
> 
> OK.  Is this true if you do it per basic block after inlining?
> 
> Brad




More information about the Gambit-list mailing list