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 locatedargument 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 wecall another JS function.
I would be fine with going with such an implementation. But the higher-levelissue 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 handlerwhich 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. https://codereview.chromium.org/1294133004/ -- -- v8-dev mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
