Re: compile-rtl

[Andy Wingo]

On Sat 26 Jan 2013 13:28, Stefan Israelsson Tampe <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>
>>> Now when we are tail-calling in rtl, we just fill the argument slots
>>> with the new function arguments directly and then tail-call by filling
>>> in
>>> number of arguments and function. This is very smart and just some
>>> simple features added would mean that a lot of translation
>>> from one memory location to the other is skipped. I really like how the
>>> rtl code handle this but there is an expense. It complicates life a
>>> little
>>> when we overwrite arguments that are used in the calculation of other
>>> arguments. I'm working on how to handle this but I just wanted to point
>>> out how nice this design choice is.
>>
>> Thanks!  In general at the end you have a parallel register move (or
>> parallel assignment), which has a number of standard solutions out
>> there.
>
> This is quite a natural first step. But especially for loops there is
> a similar tail pattern that probably needs to be optimized better w.r.t.
> register slots when we compile nativly

There are two things that can help here:

  (1) Tight allocation of registers (VM or native).  Registers should be
      allocated not just in terms of scope but in terms of where they
      are used -- after their last use they are dead and so the register
      is available for some other purpose.  This can allow the loop
      variables in a loop can be updated in-place, without shuffling.

  (2) For the native case, native register allocation.  I've worked with
      linear scan before and it seems pretty good, and we could do it
      directly on the CPS form; Wimmer et al are able to do it on SSA
      form, so I don't see why not.

Andy
-- 
http://wingolog.org/