[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Mon, 21 Jan 2013 18:32:03 +0100
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)
On Sun 14 Oct 2012 17:13, Stefan Israelsson Tampe <address@hidden> writes:
> potential memory leaks. To let it be as it is designed right now, will
> mean that it is very difficult looking at the scheme code to see what
> will be protected from gc or not.
Explicit clearing is much better than a stack pointer. We can be much
smarter about it.
> 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
> call's, here currently we send a list of register positions to the call
> function and the call function itself will copy those to the argument
> fields. This is the opposite
> of the tail-call, in a case like (f 1 3) you will create two temporary
> variables and copy them later on to the argument position. Here I would
> like to change the
> semantic so that we fill in the arguments directly just like in the
We can't do this unless we reintroduce a stack pointer, I don't think;
and anyway reopening the hole for the in-progress frame is pretty nasty
for the runtime (the backtrace code in particular). Dunno. I'm
hesitant to change this.
> Also, I would like to use the end of the stack region to compute the
> function frame. Well even if we use the end of the full frame we will
> save one move per argument which is nice.
This is possible I guess, but again makes tooling a bit difficult.
> Return values.
> We talked about this before and there is some concerns how to make this
> fast. I would like to skip the complication by simply put the return
> values in the
> argument positions to the function. Also the number of arguments is
> mediated to the reciever. I would like to skip the mv-return slot
Have you been working off of wip-rtl after the commit, "remove
return_loc, instead put mv returns on the stack" ? Does that not solve
the issue for you? After that commit, there will be no more MVRA
(though it is still there while the VM is in a transitional state).
- Re: compile-rtl,
Andy Wingo <=