Port r14434 (04f254d1)
Original commit message:
Previously there has been no reason to context-allocate the receiver, so
access to the receiver always goes through the stack. This was failing
with generators, which assumed that forcing context allocation would
relieve the need of storing anything but the context and the function on
the stack.
This CL adds a slot in generator objects to capture the receiver, and
restores it when resuming a generator.
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/14195033
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14442 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r14415 (d358defa) and r14424 (7b549ce7)
Original commit message:
The generator object methods "next", "send", and "throw" now
include some inline assembly to set up a resumed stack frame. In some
common cases, we can just jump back into the frame to resume it.
Otherwise the resume code calls out to a runtime to fill in the operand
stack, rewind the handlers, and possibly to throw an exception.
BUG=v8:2355
TESTS=mjsunit/harmony/generators-iteration
Review URL: https://codereview.chromium.org/13864010
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14428 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* All Lithium instructions have an associated Hydrogen instruction now,
simplifying things.
* Consistently print <Lithium instruction number,Hydrogen value id> prefixes.
* Do not print uninteresting Lithium instructions like empty gaps, jumps to the
next instruction, etc.
* Removed special handling of HChange-like instructions, it is totally unclear
why they had this special treatment. If we really want to print more
information about Lithium instructions, we should do it in a totally way,
anyway (e.g. by unifying things with the generation of hydrogen*.cfg files).
* Made deferred code and the jump table stand out a little bit more.
* Print info about special blocks like loop headers and OSR entries.
Review URL: https://codereview.chromium.org/14371005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14370 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r14353 (f4bb81d1)
Original commit message:
* src/ast.h:
* src/parser.cc: Differentiate between the different kinds of yields, in
anticipation of boxing return values. Parse `return' into `yield' in
a generator.
* src/runtime.h:
* src/runtime.cc (Runtime_SuspendJSGeneratorObject): New horrible
runtime function: saves continuation, context, and operands into the
generator object.
* src/arm/full-codegen-arm.cc (VisitYield):
* src/ia32/full-codegen-ia32.cc (VisitYield):
* src/x64/full-codegen-x64.cc (VisitYield): Arrange to call
SuspendJSGeneratorObject. If the call returns the hole, we suspend.
Otherwise we resume.
BUG=v8:2355
TEST=These codepaths are tested when the generator is first invoked, and so
are covered by mjsunit/harmony/generators-objects.js.
Review URL: https://codereview.chromium.org/14091006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14363 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r14230 (76c22097)
Original commit message:
Native method invocation from the arm/simulator-arm.cc previously made
non-portable assumptions about calling conventions. This was okay for 32-bit
stack-based machines, where by-value structs are automatically materialized
on the stack, and where both int and double parameters could be passed on the
stack. However they are not okay for x86-64, which has an elaborate scheme
for passing parameters in registers.
This CL replaces the previous non-portable code paths with portable code,
using call-sites that accurately match the prototype of the callee.
BUG=
Review URL: https://codereview.chromium.org/13989008
Patch from Akos Palfi <palfia@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14239 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r14236 (7d56d7c5)
Original commit message:
* src/generator.js: Add methods and intialization for generator meta-objects.
* src/contexts.h:
* src/bootstrapper.cc (InitializeExperimentalGlobal): Make generator
meta-objects, and store maps for constructing generator functions
and their prototypes.
* src/factory.h:
* src/factory.cc (MapForNewFunction): New helper.
(NewFunctionFromSharedFunctionInfo): Use the new helper.
* src/heap.cc (AllocateFunctionPrototype, AllocateInitialMap): For
generators, allocate appropriate prototypes and maps.
* src/code-stubs.h:
* src/arm/code-stubs-arm.h:
* src/arm/full-codegen-arm.h:
* src/ia32/code-stubs-ia32.h:
* src/ia32/full-codegen-ia32.h:
* src/x64/code-stubs-x64.h:
* src/x64/full-codegen-x64.h: Allow fast closure creation for generators,
using the appropriate map.
* test/mjsunit/harmony/builtins.js: Add a special case for
GeneratorFunctionPrototype.prototype.__proto__.
BUG=
Review URL: https://codereview.chromium.org/13988003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14238 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This makes the logic in the Hydrogen->Lithium translation much clearer, avoids a
hand-written dispatch and even opened up opportunities for simpler register
constraints for some operations/platforms.
Doing the same for the Hydrogen level might be done in a follow-up CL.
Review URL: https://codereview.chromium.org/13841003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14233 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Native method invocation from the arm/simulator-arm.cc previously made
non-portable assumptions about calling conventions. This was okay for 32-bit
stack-based machines, where by-value structs are automatically materialized
on the stack, and where both int and double parameters could be passed on the
stack. However they are not okay for x86-64, which has an elaborate scheme
for passing parameters in registers.
This CL replaces the previous non-portable code paths with portable code,
using call-sites that accurately match the prototype of the callee.
BUG=2614
Review URL: https://chromiumcodereview.appspot.com/13818012
Patch from Brad Chen <bradchen@google.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14230 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Port r14152 (4e58a8ea)
Original commit message:
* src/scopes.h (ForceContextAllocation, has_forced_context_allocation):
New interface to force context allocation for an entire function's
scope.
* src/scopes.cc: Unless a new scope is a function scope, if its outer
scope has forced context allocation, it should also force context
allocation.
(MustAllocateInContext): Return true if the scope as a whole has
forced context allocation.
(CollectStackAndContextLocals): Allow temporaries to be
context-allocated.
* src/parser.cc (ParseFunctionLiteral): Force context allocation for
generator scopes.
* src/v8globals.h (VariableMode): Update comment on TEMPORARY.
* src/arm/full-codegen-arm.cc (Generate):
* src/ia32/full-codegen-ia32.cc (Generate):
* src/x64/full-codegen-x64.cc (Generate): Assert that generators have no
stack slots.
* test/mjsunit/harmony/generators-instantiation.js: New test.
BUG=
Review URL: https://codereview.chromium.org/13726009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14157 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
