Ideally this would have been implemented via desugaring at parse-time,
but yield* is an expression, and its desugaring includes statements like
while and try/catch. We'd have to have BlockExpression in the AST to
support that, and it's not worth it for this feature.
So instead we implement all of the logic in
FullCodeGenerator::VisitYield. Delegating yield AST nodes now have a
try handler index, for the try/catch. Otherwise the implementation is
straightforward.
R=mstarzinger@chromium.org
BUG=v8:2355
TEST=mjsunit/harmony/generators-iteration
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14666 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is a resubmit of codereview.chromium.org/13818012 with the following modifications:
- src/x64/code-stubs-x64.cc for changes specific to Win64 calling conventions.
- src/sampler.cc for Native Client support
BUG=v8:2614
Review URL: https://codereview.chromium.org/14305029
Patch from Brad Chen <bradchen@google.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14491 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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/14158006
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14434 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
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/14066016
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14415 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
A previous change erroneously stopped saving fp registers for write stubs in
snapshotted code. This CL restores correct behavior, and makes sure code that
saves fp registers checks at runtime for 16 or 32 fp registers. Also fix a bug
in the arm simulator debugger.
BUG=
Review URL: https://codereview.chromium.org/14246032
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14359 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* 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/13704010
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14353 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This patch defines new makefile command line paramaters to better control the
ARM specific options. The new paramters are
* armfpu = vfp, vfpv3-d16, vfpv3, neon.
* armfloatabi = softfp, hard
* armneon = on
* armthumb = on, off
* armtest = on
One existing paratemer has been modified:
* armv7 = true, false
A number of parameters have been deprecated (but are still working):
* hardfp = on, off
* vfp2 = off
* vfp3 = off
the armtest paratmer when set to "on" will lock the options used during compile
time at runtime. This allows for example to easily test the ARMv6 build on an
ARMv7 platform without having to worry about features detected at runtime. When
not specified the compiler default will be used meaning it is not necessary
anymore to specify hardfp=on when natively building on an hardfp platform.
The shell help now prints the target options and features detected.
BUG=none
TEST=none
Review URL: https://chromiumcodereview.appspot.com/14263018
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14288 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
* 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=
TEST=mjsunit/harmony/generators-runtime
Review URL: https://codereview.chromium.org/13192004
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14236 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
* 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=v8:2355
TEST=mjsunit/harmony/generators-instantiation
Review URL: https://codereview.chromium.org/13408005
Patch from Andy Wingo <wingo@igalia.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14152 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
If we find a property in the prototype-chain that we can overwrite, and
we have a transition, keep the holder in the lookup-result as the actual
holder. We will need it for the consistency-check in GenerateStoreField.
By directly checking the entire chain we avoid having to lazily bail out
to a copy of the miss stub while generating the Field Store IC.
Currently this CL disallows a normal non-receiver holder, given that
that would require a positive lookup + details verification to ensure
the property did not become read-only. This fixes the regressions in the
attached tests.
Review URL: https://chromiumcodereview.appspot.com/12810006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
(qua last week's TC39)
Specifically:
- Install Symbol constructor function on the global object.
- Adjust code generation for typeof.
- Remove IsSymbol built-in, IS_SYMBOL macro now defined using typeof.
- Remove hack that allowed symbols as constructor results, and some other special cases.
- Remove symbol_delegate and GetDelegate function.
- Extend ToBoolean stub to handle symbols.
- Extend ToNumber to return NaN on symbols.
- Poison symbol's toString function, and thereby ToString on symbols.
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12957004
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14051 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Addition of a compiled hydrogen stub for KeyedStores.
- Inlining of "grow" stubs into OPTIMIZED_FUNCTIONs
- Addition of new "ignore OOB" ic stub that silently swallows out-of-bounds stores to external typed arrays.
- Addition of new "copy-on-write" ic stub that inlines allocation and copying operations for cow array
- New stub are generated with Crankshaft, so they are automatically inlined into OPTIMIZED_FUNCTIONs
Review URL: https://codereview.chromium.org/12221064
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14001 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
After r13912, we saw a small regression in Kraken crypto-aes and
crypto-ccm on Nexus 4. This patch, proposed by Rodolph Perfetta,
addresses that without regressing other platforms.
Instead of looking at the exponent of double_input and trying to figure
out if the conversion will overflow, eagerly do the VCVT and return
early unless it saturated.
BUG=none
Review URL: https://chromiumcodereview.appspot.com/12544025
Patch from Hans Wennborg <hans@chromium.org>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13948 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Minor cleanups on the way, e.g. making sure that we never use something after an allocation failed. Style question: Should we switch to some kind of MUST_USE_RESULT-style to ensure that we handle failures consistently? Not sure...
BUG=v8:2576
Review URL: https://codereview.chromium.org/12867002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13946 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
First of all, it has nothing to do with Isolates, it is related to the assembler
at hand. Furthermore, the saving/restoring is platform-independent. Cleaned up
some platform-specific stuff on the way.
Note that there are some things which still need some cleanup, like e.g. using
EnumSet instead of uint64_t, making Probe() more uniform across platforms etc.,
but the CL is already big enough.
BUG=v8:2487
Review URL: https://codereview.chromium.org/12391055
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13823 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Since symbols and strings share a common representation, most of this change is about consistently replacing 'String' with 'Name' in all places where property names are expected. In particular, no new logic at all is necessary for maps, property dictionaries, or transitions. :) The only places where an actual case distinction is needed have to do with generated type checks, and with conversions of names to strings (especially in logger and profiler).
Left in some TODOs wrt to the API: interceptors and native getters don't accept symbols as property names yet, because that would require extending the external v8.h.
(Baseline CL: https://codereview.chromium.org/12296026/)
R=verwaest@chromium.org,mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12330012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13811 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
- Add --harmony-symbols flag.
- Add Symbol constructor; allow symbols as (unreplaced) return value from constructors.
- Introduce %CreateSymbol and %_IsSymbol natives and respective instructions.
- Extend 'typeof' code generation to handle symbols.
- Extend CompareIC with a UNIQUE_NAMES state that (uniformly) handles internalized strings and symbols.
- Property lookup delegates to SymbolDelegate object for symbols, which only carries the toString method.
- Extend Object.prototype.toString to recognise symbols.
Per the current draft spec, symbols are actually pseudo objects that are frozen with a null prototype and only one property (toString). For simplicity, we do not treat them as proper objects for now, although typeof will return "object". Only property access works as if they were (frozen) objects (via the internal delegate object).
(Baseline CL: https://codereview.chromium.org/12223071/)
R=mstarzinger@chromium.org
BUG=v8:2158
Review URL: https://codereview.chromium.org/12296026
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13786 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
in preparation of the introduction of ES6 'symbols' (aka private/unique names).
The SymbolTable became the StringTable. I also made sure to adapt all comments. The only remaining use of the term "symbol" (other than unrelated uses in the parser and such) is now 'NewSymbol' in the API and the 'V8.KeyedLoadGenericSymbol' counter, changing which might break embedders.
The one functional change in this CL is that I removed the former 'empty_string' constant, since it is redundant given the 'empty_symbol' constant that we also had (and both were used inconsistently).
R=yangguo@chromium.org
BUG=
Review URL: https://codereview.chromium.org/12210083
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13781 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This fixes the deoptimizer to materialize arguments objects of correct
length even in cases where the actual argument values are unknown and
were optimized away by Crankshaft. This can happen if only the length
property or the identity of an arguments object is used.
R=svenpanne@chromium.org
BUG=chromium:163530
TEST=mjsunit/regress/regress-crbug-163530
Review URL: https://codereview.chromium.org/12335132
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13763 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
