Introduces:
- a new AST node representing the GetIterator() algorithm in the specification, to be used by ForOfStatement, YieldExpression (in the case of delegating yield*), and the future `for-await-of` loop proposed in http://tc39.github.io/proposal-async-iteration/#sec-async-iterator-value-unwrap-functions.
- a new opcode (JumpIfJSReceiver), which is useful for `if Type(object) is not Object` checks which are common throughout the specification. This node is easily eliminated by TurboFan.
The AST node is desugared specially in bytecode, rather than manually when building the AST. The benefit of this is that desugaring in the BytecodeGenerator is much simpler and easier to understand than desugaring the AST.
This also reduces parse time very slightly, and allows us to use LoadIC rather than KeyedLoadIC, which seems to have better baseline performance. This results in a ~20% improvement in test/js-perf-test/Iterators micro-benchmarks, which I believe owes to the use of the slightly faster LoadIC as opposed to the KeyedLoadIC in the baseline case. Both produce identical optimized code via TurboFan when the type check can be eliminated, and the load can be replaced with a constant value.
BUG=v8:4280
R=bmeurer@chromium.org, rmcilroy@chromium.org, adamk@chromium.org, neis@chromium.org, jarin@chromium.orgTBR=rossberg@chromium.org
Review-Url: https://codereview.chromium.org/2557593004
Cr-Commit-Position: refs/heads/master@{#41555}
Since we OSR code rarely, it makes sense to store it and look for it on the native context rather than the SharedFunctionInfo. This makes the OptimizedCodeMap data structure more space efficient, as it doesn't have to store an ast ID for the OSR entry point.
BUG=
Review-Url: https://codereview.chromium.org/2549753002
Cr-Commit-Position: refs/heads/master@{#41554}
This allows to detect a static property also named 'name', and also makes sure 'name' is added last, to be standards-compliant.
BUG=v8:4199
Review-Url: https://codereview.chromium.org/2423053002
Cr-Commit-Position: refs/heads/master@{#41546}
This just calls into a runtime function for implementation currently.
Intermediate step in speeding up constructor calls containing a spread.
The NewWithSpread bytecode will probably end up having different arguments with future CLs - the constructor and the new.target should have their own regs. For now we are calling into the runtime function, so we need the regs together.
BUG=v8:5659
Review-Url: https://codereview.chromium.org/2541113004
Cr-Commit-Position: refs/heads/master@{#41542}
Equality with null/undefined is equivalent to a check on the undetectable bit
on the map of the object. This would be more efficient than performing the entire
comparison operation.
This cl introduces:
1. A new bytecode called TestUndetectable that checks if the object is null/undefined.
2. Updates peeophole optimizer to emit TestUndetectable when a LdaNull/Undefined
precedes equality check.
4. TestUndetectable is transformed to ObjectIsUndetectable operator when building
turbofan graph.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2547043002
Cr-Commit-Position: refs/heads/master@{#41514}
Unfortunately we have to split this up into two cases: those with exactly one spread argument as the final argument, and all others, due to any side-effects of evaluation being visible.
This is in preparation for a new bytecode which handles super calls.
BUG=v8:5659
Review-Url: https://codereview.chromium.org/2540593003
Cr-Commit-Position: refs/heads/master@{#41415}
Removed a redundant check: If completion is not normal, then #iterator cannot be undefined.
Review-Url: https://codereview.chromium.org/2533803002
Cr-Commit-Position: refs/heads/master@{#41321}
Add bytecode for defining data properties, which initially just calls the runtime function.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2510743002
Cr-Commit-Position: refs/heads/master@{#41101}
The reasons are:
1) The names dictionaries in the feedback metadata seems to consume a lot of memory
and the idea didn't payoff.
2) The absence of a name parameter blocks data handlers support in LoadGlobalIC.
This CL reverts a part of r37278 (https://codereview.chromium.org/2096653003/).
BUG=chromium:576312, v8:5561
Review-Url: https://codereview.chromium.org/2510653002
Cr-Commit-Position: refs/heads/master@{#41046}
Adds a bytecode to set and retrieve the pending message. This avoids a
runtime call in finally blocks, and also ensures that TurboFan builds a
graph using the SetMessage / LoadMessage nodes instead of inserting a
runtime call.
BUG=chromium:662334
Review-Url: https://codereview.chromium.org/2501503005
Cr-Commit-Position: refs/heads/master@{#41023}
Avoid using the iterator for arrays with fast elements where the iterator has
not been modified.
Only deals with the case where there is a single spread argument.
Improves the six-speed "spread" benchmark to 1.5x slower than baseline es5 implementation, compared to 19x slower previously.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2465253011
Cr-Commit-Position: refs/heads/master@{#40998}
This removes the POSSIBLY_EVAL_CALL call type, and instead uses OTHER_CALL
or WITH_CALL to decide whether to do the special LOOKUP_SLOT_CALL runtime
call to find the callee and possibly update the receiver with the with-object.
This means that eval calls out of 'with' blocks can now just do a normal
LdaLookupGlobalSlot operation, which can check the context chain for eval
extentions and fast-path the lookup if none exist.
BUG=661556
Review-Url: https://codereview.chromium.org/2487483004
Cr-Commit-Position: refs/heads/master@{#40965}
This replaces LOOKUP_SLOT_CALL with WITH_CALL, and relies on regular lookup-slot handling in variable load to support other lookup slots (variables resolved in the context of sloppy eval). This allows optimizations for such variable loads to kick in for calls as well. We only need special handling for function calls in the context of with, since it changes the receiver of the call from undefined/global to the with-object.
This currently doesn't yet make it work for the direct eval call itself, since the POSSIBLY_EVAL_CALL flag is also used to deal with direct eval later.
BUG=
Review-Url: https://codereview.chromium.org/2480253006
Cr-Commit-Position: refs/heads/master@{#40962}
- A new runtime function (%create_resolving_functions) is installed to
call the CreateResolvingFunctions builtin from JS.
- Three new builtins are created - resolve and reject functions and a
third function that creates a new JSFunctions from these
resolve/reject builtins.
- The promise reject function is installed on the context temporarily
as internal_promise_reject. This should go away once we remove
PromiseSet.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2459283004
Cr-Commit-Position: refs/heads/master@{#40903}
We seem to get some small wins from avoiding the Ldr bytecodes, probably due
to reduced icache pressure since there are less bytecode handlers. Replace
the Ldr bytecodes with Star lookahead inlined into the Lda versions.
Also fixes IsAccumulatorLoadWithoutEffects to include LdaContextSlot and
LdaCurrentContextSlot
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2489513005
Cr-Commit-Position: refs/heads/master@{#40883}
The Ldr[Named/Keyed]Property bytecodes are problematic for the deoptimizer when
inlining accessors in TurboFan. Remove them and replace with a Star lookahead
in the bytecode handlers for Lda[Named/Keyed]Property.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2485383002
Cr-Commit-Position: refs/heads/master@{#40860}
This introduces two new bytecodes LdaModuleVariable and StaModuleVariable,
replacing the corresponding runtime calls.
Support in the bytecode graph builder exists only in the form of runtime calls.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2471033004
Cr-Commit-Position: refs/heads/master@{#40825}
This makes use of the newly introduced cell indices to speed up variable
accesses. Imports and local exports are now directly stored in (separate)
arrays. In the future, we may merge the two arrays into a single one, or
even into the module context.
This CL also replaces the LoadImport and LoadExport runtime functions with
a single LoadVariable taking a variable index as argument (rather than a
name).
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2465283004
Cr-Commit-Position: refs/heads/master@{#40808}
The majority of context slot accesses are to the local context (current context
register and depth 0), so this adds bytecodes to optimise for that case.
This cuts down bytecode size by roughly 1% (measured on Octane and Top25).
Review-Url: https://codereview.chromium.org/2459513002
Cr-Commit-Position: refs/heads/master@{#40641}
This is a new bytecode which behaves (for now) exactly like Call,
except that in turbofan graph building we can set the
ConvertReceiverMode to NotNullOrUndefined.
I observe a 1% improvement on Box2D, I'd expect a similar improvement on
other OOP heavy code.
Review-Url: https://codereview.chromium.org/2450243002
Cr-Commit-Position: refs/heads/master@{#40610}
Move hole check logic from full-codegen into scope analysis, and store the
"needs hole check" bit on VariableProxy. This makes it easy to re-use in
any backend: it will be trivial to extend the use of this logic in, e.g.,
full-codegen variable stores.
While changing the signatures of the variable loading/storing methods in
Ignition, I took the liberty of replacing the verb "Visit" with "Build", since these
are not part of AST visiting.
BUG=v8:5460
Review-Url: https://chromiumcodereview.appspot.com/2411873004
Cr-Commit-Position: refs/heads/master@{#40479}
Consistently collect CallIC feedback in fullcodegen and Ignition, even
for possibly direct eval calls, that were treated specially so far, for
no apparent reason. With the upcoming SharedFunctionInfo based CallIC
feedback, we might be able to even inline certain direct eval calls, if
they manage to hit the eval cache. More importantly, this patch
simplifies the collection and dealing with CallIC feedback (and as a
side effect fixes an inconsistency with feedback for super constructor
calls).
R=mvstanton@chromium.org, mythria@chromium.org
BUG=v8:2206,v8:4280,v8:5267
Review-Url: https://codereview.chromium.org/2426693002
Cr-Commit-Position: refs/heads/master@{#40397}
This makes optimization of all class constructors (i.e. both base and
derived) go through TurboFan. Note some class constructors containing
Harmony language features (e.g. super constructor calls or accesses to
the new.target value) were already going through TurboFan before.
R=bmeurer@chromium.org
BUG=v8:5458
Review-Url: https://codereview.chromium.org/2397723002
Cr-Commit-Position: refs/heads/master@{#40342}
In order to optimize super constructor calls with ES6 classes, we need
some feedback for both the JSCallConstruct and the resulting JSCreate
nodes in TurboFan. Both already optimize perfectly when the see nodes
with JSFunction constants, so utilizing the existing CallIC machinery
here, enables us to optimize the super constructor calls right now w/o
a lot of effort.
Note that there are probably better ways to track this information,
for example we could do some tracking on the constructor functions;
this will however require serious changes in TurboFan and the runtime,
and would block progress on more important tasks.
R=mythria@chromium.org
BUG=v8:5517
Review-Url: https://codereview.chromium.org/2419423002
Cr-Commit-Position: refs/heads/master@{#40337}
Now that all accesses to the last match info are in C++ and TF code, we can
finally turn the last match info into a FixedArray. Similar to the ArrayList,
it uses its first field to store its length and grows dynamically in amortized
O(1) time.
Unlike previously, this means that the last match info pointer stored on the
context can actually change (in case the FixedArray needs to grow).
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2415103002
Cr-Commit-Position: refs/heads/master@{#40308}
This ports RegExpInitialize, IsRegExp, InternalMatch and InternalReplace to C++
/ TurboFan. InternalMatch is in TurboFan because it calls RegExpExecStub and
needs to construct a RegExpResult (which are, respectively, a PlatformStub and
a CodeStubAssembler function).
Except for LastMatchInfo (and GetSubstitution, which could be moved to string.js
anytime), regexp.js is now completely empty.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2409513003
Cr-Commit-Position: refs/heads/master@{#40277}
This moves the implementation of @@replace from regexp.js to builtins-regexp.cc
(the TurboFan fast path) and runtime-regexp.cc (slow path). The fast path
handles all cases in which the regexp itself is an unmodified JSRegExp
instance, the given 'replace' argument is not callable and does not contain any
'$' characters (i.e. we are doing a string replacement).
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2398423002
Cr-Commit-Position: refs/heads/master@{#40253}
This CL ports RegExp.prototype.test, RegExp.prototype.match
and RegExp.prototype.search to C++.
Performance regressions are expected but should be improved
in an upcoming CL.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2394713003
Cr-Commit-Position: refs/heads/master@{#40122}
This implements namespace imports (import * as foo from "bar"), except for the
@@iterator property on namespace objects (to be done later).
R=adamk@chromium.org
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2388153003
Cr-Commit-Position: refs/heads/master@{#40096}
There are only a few occasions where we allocate a register in an outer
expression allocation scope, which makes the costly free-list approach
of the BytecodeRegisterAllocator unecessary. This CL replaces all
occurrences with moves to the accumulator and stores to a register
allocated in the correct scope. By doing this, we can simplify the
BytecodeRegisterAllocator to be a simple bump-pointer allocator
with registers released in the same order as allocated.
The following changes are also made:
- Make BytecodeRegisterOptimizer able to use registers which have been
unallocated, but not yet reused
- Remove RegisterExpressionResultScope and rename
AccumulatorExpressionResultScope to ValueExpressionResultScope
- Introduce RegisterList to represent consecutive register
allocations, and use this for operands to call bytecodes.
By avoiding the free-list handling, this gives another couple of
percent on CodeLoad.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2369873002
Cr-Commit-Position: refs/heads/master@{#39905}
Before evaluating a module, all variables declared at the top-level
in _any_ of the modules in the dependency graph must be initialized.
This is observable because a module A can access a variable imported
from module B (e.g. a function) at a point when module B's body hasn't
been evaluated yet.
We achieve this by implementing modules internally as generators with
two states (not initialized, initialized).
R=adamk@chromium.org
BUG=v8:1569
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg
Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
Committed: https://crrev.com/8c52a411583e870bd5ed100864caa58f491c5d88
Review-Url: https://codereview.chromium.org/2375793002
Cr-Original-Original-Commit-Position: refs/heads/master@{#39871}
Cr-Original-Commit-Position: refs/heads/master@{#39892}
Cr-Commit-Position: refs/heads/master@{#39900}
Reason for revert:
Speculative revert for christmas tree
Original issue's description:
> Reland: [modules] Properly initialize declared variables.
>
> Before evaluating a module, all variables declared at the top-level
> in _any_ of the modules in the dependency graph must be initialized.
> This is observable because a module A can access a variable imported
> from module B (e.g. a function) at a point when module B's body hasn't
> been evaluated yet.
>
> We achieve this by implementing modules internally as generators with
> two states (not initialized, initialized).
>
> R=adamk@chromium.org
> BUG=v8:1569
> CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg
>
> Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
> Committed: https://crrev.com/8c52a411583e870bd5ed100864caa58f491c5d88
> Cr-Original-Commit-Position: refs/heads/master@{#39871}
> Cr-Commit-Position: refs/heads/master@{#39892}
TBR=adamk@chromium.org,mstarzinger@chromium.org,machenbach@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2387593002
Cr-Commit-Position: refs/heads/master@{#39896}
Before evaluating a module, all variables declared at the top-level
in _any_ of the modules in the dependency graph must be initialized.
This is observable because a module A can access a variable imported
from module B (e.g. a function) at a point when module B's body hasn't
been evaluated yet.
We achieve this by implementing modules internally as generators with
two states (not initialized, initialized).
R=adamk@chromium.org
BUG=v8:1569
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg
Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
Review-Url: https://codereview.chromium.org/2375793002
Cr-Original-Commit-Position: refs/heads/master@{#39871}
Cr-Commit-Position: refs/heads/master@{#39892}
Reason for revert:
Suspect for causing win64 debug problems:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12646
Original issue's description:
> [modules] Properly initialize declared variables.
>
> Before evaluating a module, all variables declared at the top-level
> in _any_ of the modules in the dependency graph must be initialized.
> This is observable because a module A can access a variable imported
> from module B (e.g. a function) at a point when module B's body hasn't
> been evaluated yet.
>
> We achieve this by implementing modules internally as generators with
> two states (not initialized, initialized).
>
> R=adamk@chromium.org
> BUG=v8:1569
>
> Committed: https://crrev.com/f4dfb6fbe1cdd9a0f287a1a9c496e1f69f6f5d20
> Cr-Commit-Position: refs/heads/master@{#39871}
TBR=adamk@chromium.org,mstarzinger@chromium.org,neis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2379063002
Cr-Commit-Position: refs/heads/master@{#39873}
Before evaluating a module, all variables declared at the top-level
in _any_ of the modules in the dependency graph must be initialized.
This is observable because a module A can access a variable imported
from module B (e.g. a function) at a point when module B's body hasn't
been evaluated yet.
We achieve this by implementing modules internally as generators with
two states (not initialized, initialized).
R=adamk@chromium.org
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2375793002
Cr-Commit-Position: refs/heads/master@{#39871}
Use an unordered_map<Module, unordered_set<String>> to keep track
of visited Module/ExportName pairs during ResolveExport.
This required adding a Hash() method to Module, which is accomplished
by allocating a Symbol and storing it in the SharedFunctionInfo::name
slot, then delegating the hash to that Symbol.
Also added a helper method Module::shared() to easily get ahold of
the SharedFunctionInfo and call it in the appropriate places instead
of re-doing the ternary operator.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2367623004
Cr-Commit-Position: refs/heads/master@{#39743}
Reason for revert:
Tanks EarleyBoyer.
Original issue's description:
> [compiler] Properly guard the speculative optimizations for instanceof.
>
> Add a general feedback slot for instanceof similar to what we already have
> for for-in, which basically has a fast (indicated by the uninitialized
> sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
> we can only take the fast path when the feedback slot says it hasn't
> seen any funky inputs and nothing funky appeared in the prototype chain.
> In the TurboFan code we also deoptimize whenever we see a funky object
> (i.e. a proxy or an object that requires access checks) in the prototype
> chain (similar to what Crankshaft already did).
>
> Drive-by-fix: Also make Crankshaft respect the mode and therefore
> address the deopt loop in Crankshaft around instanceof.
>
> We might want to introduce an InstanceOfIC mechanism at some point and
> track the map of the right-hand side.
>
> BUG=v8:5267
> R=mvstanton@chromium.org
>
> Committed: https://crrev.com/a0484bc6116ebc2b855de87d862945e2ae07169b
> Cr-Commit-Position: refs/heads/master@{#39718}
TBR=mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2365223003
Cr-Commit-Position: refs/heads/master@{#39736}
Add a general feedback slot for instanceof similar to what we already have
for for-in, which basically has a fast (indicated by the uninitialized
sentinel) and a slow (indicated by the megamorphic sentinel) mode. Now
we can only take the fast path when the feedback slot says it hasn't
seen any funky inputs and nothing funky appeared in the prototype chain.
In the TurboFan code we also deoptimize whenever we see a funky object
(i.e. a proxy or an object that requires access checks) in the prototype
chain (similar to what Crankshaft already did).
Drive-by-fix: Also make Crankshaft respect the mode and therefore
address the deopt loop in Crankshaft around instanceof.
We might want to introduce an InstanceOfIC mechanism at some point and
track the map of the right-hand side.
BUG=v8:5267
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2370693002
Cr-Commit-Position: refs/heads/master@{#39718}
