From: Andy Wingo <wingo@pobox.com>
To: Stefan Israelsson Tampe <stefan.itampe@gmail.com>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: compile-rtl
Date: Sun, 27 Jan 2013 11:28:05 +0100 [thread overview]
Message-ID: <87sj5m9ayy.fsf@pobox.com> (raw)
In-Reply-To: <5103cae3.886a980a.4bbe.4e2b@mx.google.com> (Stefan Israelsson Tampe's message of "Sat, 26 Jan 2013 13:28:37 +0100")
On Sat 26 Jan 2013 13:28, Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
> Andy Wingo <wingo@pobox.com> 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/
prev parent reply other threads:[~2013-01-27 10:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-14 15:13 compile-rtl Stefan Israelsson Tampe
2013-01-21 17:32 ` compile-rtl Andy Wingo
2013-01-21 19:01 ` compile-rtl Stefan Israelsson Tampe
2013-01-26 12:28 ` compile-rtl Stefan Israelsson Tampe
2013-01-27 10:28 ` Andy Wingo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sj5m9ayy.fsf@pobox.com \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
--cc=stefan.itampe@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).