[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sun, 27 Jan 2013 11:28:05 +0100
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)
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
>>> 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
>>> 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
> 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.