On 2015/08/19 16:41:52, Michael Starzinger wrote:
On 2015/08/19 15:42:16, rmcilroy wrote:
> On 2015/08/19 15:15:37, Michael Starzinger wrote:
> > High level question: Do we need to keep the context in a machine
register?
Or
> > could be but it into one of the interpreter registers thereby avoiding
pinning
> > yet another machine register.
>
> I don't want to have it in an interpreter Register, otherwise the
> BytecodeArrayBuilder needs to know about it, which could get messy.
>
> On ia32 it is already passed as a stack slot (effectively a stack
located
> argument to the Bytecode handler) so it isn't using an extra register
there.
For
> other architectures we have plenty of registers and I would prefer we
have
it
in
> the standard context register, that way we don't need to load it every
time
we
> call another JS function.
I would be fine with going with such an implementation. But the
higher-level
issue I wanted to raise is that it's not entirely clear to me how the
context
chain should be represented in the bytecode. Going with this approach I
assume
means that there is one dedicated context parameter to each bytecode
handler
which most handlers will pass through only some {ContextPush} and
{ContextPop}
will actually update that parameter to point to something else before
doing
the
next interpreter dispatch. That in turn means that the translation from
bytecode
to a graph would then SSA-rename this slot when compiling from bytecode.
Totally
valid approach.
An alternative approach would be, to do the renaming when building the
bytecode,
put the context into an interpreter register, also put context chain
extensions
into (other) interpreter registers. This would make {ContextPush} and
{ContextPop} bytecodes unnecessary and the translation from bytecode to a
graph
would also look different. Not saying this approach is better, just
wanted to
throw it out there.
Ahh right, I see where your coming from now, thanks. I hadn't thought of the
approach of doing SSA renaming during bytecode generation for the context
chain
(I was planning on doing the ContextPush/Pop approach you mention
initially).
I'll have think about this approach and what it's implications might be for
both
the bytecode, the bytecode generator and interpreter. We should probably
sync up
offline to chat about this - I'll schedule something if we don't get to it
in
the sub team meeting.
https://codereview.chromium.org/1294133004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
