This add support for ConsString objects allocated inline to the escape
analysis pass. The raw hash field in such strings needs special handling
similar to existing raw fields. This also contains materialization code
within the deoptimizer as usual.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648737
BUG=chromium:648737
Review-Url: https://codereview.chromium.org/2357153002
Cr-Commit-Position: refs/heads/master@{#39594}
This cleanup is necessary to make HCallWithDescriptor support passing arguments on the stack.
BUG=v8:5407
Review-Url: https://codereview.chromium.org/2352163004
Cr-Commit-Position: refs/heads/master@{#39590}
This removes an optimization from the code generator that tries to
materialize certain constants (i.e. context and closure) from the
stackframe when possible. This does not work with Harmony tail calls
which are split into several instructions. There have already been
numerous bugs in this optimization, it is too fragile in its current
form.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-648539
BUG=chromium:648539
Review-Url: https://codereview.chromium.org/2357583003
Cr-Commit-Position: refs/heads/master@{#39583}
When we added the new MachineRepresentation::kTaggedSigned and
MachineRepresentation::kTaggedPointer, we didn't extend the logic
for memory operand covering, and so for map checks and other
comparisons with fields we'd always need an additional register.
This fixes that and does reduce register pressure in some cases.
R=jarin@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2354863003
Cr-Commit-Position: refs/heads/master@{#39575}
- Add a new container object to store the data required for
PromiseResolveThenableJob.
- Create a new runtime function to enqueue the microtask event with
the required data.
This patches causes a 4% regression in the bluebird benchmark.
BUG=v8:5343
Review-Url: https://codereview.chromium.org/2314903004
Cr-Commit-Position: refs/heads/master@{#39571}
This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.
BUG=v8:5409
Review-Url: https://codereview.chromium.org/2344143003
Cr-Commit-Position: refs/heads/master@{#39558}
Full code uses patching ICs for this feedback, and the interpreter uses
the type feedback vector. It's a good idea to code the vector slots
appropriately as ICs so that the runtime profiler can better gauge if
the function is ready for tiering up from Ignition to TurboFan.
As is, the feedback is stored in "general" slots which can't be
characterized by the runtime profiler into feedback states.
This CL addresses that problem. Note that it's also important to
carefully exclude these slots from the profiler's consideration when
determining if you want to optimize from Full code.
BUG=
Review-Url: https://codereview.chromium.org/2342853002
Cr-Commit-Position: refs/heads/master@{#39555}
The implicit assignment to the induction variable in a ForInStatement
has been ignored by the AST loop assignment analysis. This was hidden
for cases where the parser introduced a ".for" temporary, but triggers
when the variable is declared outside the loop.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647887
BUG=chromium:647887
Review-Url: https://codereview.chromium.org/2356733002
Cr-Commit-Position: refs/heads/master@{#39551}
Extract String feedback on Add operation and utilize to lower ConsString
creation in JSTypedLowering when we know that a String addition will
definitely result in the creation of a ConsString.
Note that Crankshaft has to guard the potential length overflow of the
resulting string with an eager deoptimization exit, while we can safely
throw an exception in that case.
Also note that the bytecode pipeline does not currently provide the
String feedback for the addition, which has to be added.
BUG=v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2354853002
Cr-Commit-Position: refs/heads/master@{#39540}
Moves the hashmap's allocator from being a parameter in the various
hashmap functions, to being a field in the hashmap itself. This
1. Protects against incorrectly passed allocators, and
2. Cleans up the API so that e.g. callers don't have to store their
allocator
This is part of a wider set of changes discussed in:
https://groups.google.com/forum/#!topic/v8-dev/QLsC0XPYLeM
Review-Url: https://codereview.chromium.org/2345233003
Cr-Commit-Position: refs/heads/master@{#39538}
Adds a fast path for loading DYNAMIC_GLOBAL variables, which are lookup
variables that can be globally loaded, without calling the runtime, as long as
there was no context extension by a sloppy eval along their context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2347143002
Cr-Commit-Position: refs/heads/master@{#39537}
When an allocation for a parent object is pretenured, also propagate
that to all allocations for objects that are (potentially) stored into
the parent object.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2348293003
Cr-Commit-Position: refs/heads/master@{#39534}
For denominators that are powers of two, replace Float64 division with
multiplication by the reciprocal.
Additionally, replace division by -1 with negation, and multiplication by two
with addition.
BUG=
Review-Url: https://codereview.chromium.org/2347573002
Cr-Commit-Position: refs/heads/master@{#39478}
Rename JSModule to Module and make it a Struct rather than a JSObject. We will
later add a separate JSModuleNamespace object to implement the 'import * as foo'
syntax.
BUG=v8:1569
Review-Url: https://codereview.chromium.org/2345823002
Cr-Commit-Position: refs/heads/master@{#39477}
Adds a fast path for loading DYNAMIC_LOCAL variables, which are lookup
variables that can be context loaded, without calling the runtime, as
long as there was no context extension by a sloppy eval along their
context chain.
BUG=v8:5263
Review-Url: https://codereview.chromium.org/2343633002
Cr-Commit-Position: refs/heads/master@{#39473}
The predicate in question should only trigger once and hence the stack
height should not be updated incrementally. This puts checks into place
ensuring this holds.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2333923008
Cr-Commit-Position: refs/heads/master@{#39472}
During feedback typing (in SimplifiedLowering) we might be able to
constant-fold a bunch of ObjectIs<Type> predicates, i.e. because we
took type feedback on the input or we narrowed the type of a Phi
because of type feedback.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2342283002
Cr-Commit-Position: refs/heads/master@{#39468}
This is one part of a WIP implementation of the stage-2 proposal to add
fields to classes: https://github.com/tc39/proposal-class-public-fields
See design doc:
https://docs.google.com/document/d/1WRtNm3ZLNJT1WVr8aq4RJuByYgfuAFAhj20LwTW6JVE/
This adds support for parsing fields in classes, including
infrastructure. In particular, it adds:
* Two booleans on function literal AST nodes
* Two compiler hints on SharedFunctionInfos representing said bools
* A new type of ClassLiteralProperty, FIELD
* Parser support for the syntax
* Syntax tests
* A flag to enable it.
Currently the fields are parsed and then droppped. Subsequent
patches will add semantics, mostly by desugaring in the parser and
the remainder in the non-crankshaft backends.
BUG=v8:5367
Review-Url: https://codereview.chromium.org/2315733003
Cr-Commit-Position: refs/heads/master@{#39459}
This CL implements the throw wasm opcode. This is a pre-requisite for
implementing try-catches in wasm.
BUG=
Review-Url: https://codereview.chromium.org/2339053003
Cr-Commit-Position: refs/heads/master@{#39449}
This handles the case where generating bytecode for inlining purposes
causes a stack overflow. We just abort inlining but also need to clear
pending exceptions.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-647217
BUG=chromium:647217
Review-Url: https://codereview.chromium.org/2339383002
Cr-Commit-Position: refs/heads/master@{#39448}
When zeroing a floating point stack slot, store the zero register directly,
rather than storing zero moved to an FP register.
BUG=
Review-Url: https://codereview.chromium.org/2339943002
Cr-Commit-Position: refs/heads/master@{#39441}
This is a first implementation of inlining into graphs that have been
created using the {BytecodeGraphBuilder}. Note that inlining sticks to
graphs of the same kind, we only ever inline AstGraph into AstGraph or
BytecodeGraph into BytecodeGraph, no mixed inlining.
R=bmeurer@chromium.org,rmcilroy@chromium.org
TEST=cctest/test-run-inlining
BUG=v8:5251
Review-Url: https://codereview.chromium.org/2262033003
Cr-Commit-Position: refs/heads/master@{#39439}
Migrate the platform DatePrototype_GetField (and all wrappers) to
TurboFan.
BUG=v8:5049
Review-Url: https://codereview.chromium.org/2263533002
Cr-Commit-Position: refs/heads/master@{#39438}
Add a dedicated simplified operator to inline the general case for the
ToBoolean conversion. In a follow up CL we will also use the ToBoolean
hints gathered by the baseline compiler.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_arm64_gc_stress_dbg
R=jarin@chromium.org
BUG=v8:5267
Committed: https://crrev.com/8c50b51ab3d21efcd2f6900d83962159f21e1590
Review-Url: https://codereview.chromium.org/2167593002
Cr-Original-Commit-Position: refs/heads/master@{#37882}
Cr-Commit-Position: refs/heads/master@{#39420}
Add a notion of "invocation count" to the baseline compilers, which
increment a special slot in the TypeFeedbackVector for each invocation
of a given function (the optimized code doesn't currently collect this
information).
Use this invocation count to relativize the call counts on the call
sites within the function, so that the inlining heuristic has a view
of relative importance of a call site rather than some absolute numbers
with unclear meaning for the current function. Also apply the call site
frequency as a factor to all frequencies in the inlinee by passing this
to the graph builders so that the importance of a call site in an
inlinee is relative to the topmost optimized function.
Note that all functions that neither have literals nor need type
feedback slots will share a single invocation count cell in the
canonical empty type feedback vector, so their invocation count is
meaningless, but that doesn't matter since we only use the invocation
count to relativize call counts within the function, which we only have
if we have at least one type feedback vector (the CallIC slot).
See the design document for additional details on this change:
https://docs.google.com/document/d/1VoYBhpDhJC4VlqMXCKvae-8IGuheBGxy32EOgC2LnT8
BUG=v8:5267,v8:5372
R=mvstanton@chromium.org,rmcilroy@chromium.org,mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2337123003
Cr-Commit-Position: refs/heads/master@{#39410}
This CL adds CSA::Retain() operation that ensures that the value is kept alive even during GC.
BUG=v8:5269
Review-Url: https://codereview.chromium.org/2330063002
Cr-Commit-Position: refs/heads/master@{#39407}
This removes some leftover code which avoided adding stack checks to
stubs being compiled via the normal JavaScript pipeline, which we no
longer do.
R=bmeurer@chromium.org
Review-Url: https://codereview.chromium.org/2333973003
Cr-Commit-Position: refs/heads/master@{#39404}
Extract the call counts from the type feedback vector during graph
building (either via the AstGraphBuilder or the BytecodeGraphBuilder),
and put them onto the JSCallFunction and JSCallConstruct operators,
so that they work even across inlinine through .apply and .call (which
was previously hacked by creating a temporary type feedback vector
for those).
The next logic step will be to make those call counts into real
relative call frequencies (also during graph building), so that we
can make inlining decisions that make sense for the function being
optimized (where absolute values are misleading).
R=jarin@chromium.org
BUG=v8:5267,v8:5372
Review-Url: https://codereview.chromium.org/2330883002
Cr-Commit-Position: refs/heads/master@{#39400}
This CL "weakens" the typer somewhat, as it was querying aspects of
Type that are within the representation dimension. It's not the right
place to do that.
BUG=
Review-Url: https://codereview.chromium.org/2320473003
Cr-Commit-Position: refs/heads/master@{#39391}
This introduces a new {JumpLoop} bytecode to combine the OSR polling
mechanism modeled by {OsrPoll} with the actual {Jump} performing the
backwards branch. This reduces the overall size and also avoids one
additional dispatch. It also makes sure that OSR polling is only done
within real loops.
R=rmcilroy@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2331033002
Cr-Commit-Position: refs/heads/master@{#39384}
When lowering DataField accesses, we should pay attention to the
MachineRepresentation reported by the AccessInfo. This doesn't
yet change the rest of the pipeline to take full advantage of
the representations.
Drive-by-fix: Make the code more robust, especially the part that
deals with mutable heap number access.
R=mvstanton@chromium.org
BUG=v8:5267,v8:5270
Review-Url: https://codereview.chromium.org/2334193002
Cr-Commit-Position: refs/heads/master@{#39381}
When inlining sloppy functions try to find some witness in the effect
chain that the receiver is already a JSReceiver and thereby avoid
inserting the JSConvertReceiver node, which we currently cannot really
optimize away most of the time.
Middle-term we may want to change the way CheckMaps works and have some
unified mechanism to deal with effect chain walks to find witnesses for
various map related facts. Also we may want to consider doing this
optimization later, although that requires some more refactorings since
we already promised that JSConvertReceiver gives a Type::Receiver.
R=mstarzinger@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2333213002
Cr-Commit-Position: refs/heads/master@{#39379}
Moves the context chain search loop out of generated bytecode, and into
the (Lda|Ldr|Sda)ContextSlot handler, by passing the context depth in as
an additional operand. This should decrease the bytecode size and
increase performance for deep context chain searches, at the cost of
slightly increasing bytecode size for shallow context access.
Review-Url: https://codereview.chromium.org/2336643002
Cr-Commit-Position: refs/heads/master@{#39378}
This makes sure OSR entry points can be added without having special
{OsrPoll} instructions in the bytecode stream. Eventually we might end
up merging back-branches and OSR polls together. Any loop header can be
used as an OSR entry point.
R=bmeurer@chromium.org
BUG=v8:4764
Review-Url: https://codereview.chromium.org/2329933003
Cr-Commit-Position: refs/heads/master@{#39373}
Don't sort inline candidates by comparing Node pointers, where the order
depends on the allocation order and the concrete Zone memory layout at
runtime. Instead sort based on NodeId, which is deterministic.
R=mvstanton@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2336113002
Cr-Commit-Position: refs/heads/master@{#39371}
Add strength reduction rules to optimize
CheckTaggedSigned(CheckTaggedSigned(x)) -> CheckTaggedSigned(x)
and
CheckTaggedPointer(CheckTaggedPointer(x)) -> CheckTaggedPointer(x)
where we do some cleanup optimizations after loop peeling and redundancy
elimination, which can generate these constructs.
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2336093002
Cr-Commit-Position: refs/heads/master@{#39366}
