v8 allows the embedder to specify a global template to use when
creating a new context. However, v8 does not use the supplied
template directly when creating the global proxy: it creates a
unique template for each global proxy. However, this is problematic
for remote contexts: functions cannot use strict receiver checks
with the remote context, as the global template will never match
the global proxy.
To fix this, remote contexts now also include a remote global
object in the prototype chain that is instantiated with the global
template. This mirrors the way the global proxy is configured for a
full v8 context, and allows strict receiver checks to work.
BUG=527190
Review-Url: https://codereview.chromium.org/2677653002
Cr-Commit-Position: refs/heads/master@{#43361}
Reason for revert:
Due to arm64 failures
Original issue's description:
> [interpreter] Create custom call opcodes for specific argument counts
>
> Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
> and CallProperty2. Also share the bytecode handler code between between
> equivalent CallX and CallPropertyX handlers.
>
> Review-Url: https://codereview.chromium.org/2684993002
> Cr-Commit-Position: refs/heads/master@{#43290}
> Committed: 00d6f1f80aTBR=rmcilroy@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
Review-Url: https://codereview.chromium.org/2709533002
Cr-Commit-Position: refs/heads/master@{#43308}
Specifically, add bytecodes for Call0, Call1, Call2, CallProperty0, CallProperty1,
and CallProperty2. Also share the bytecode handler code between between
equivalent CallX and CallPropertyX handlers.
Review-Url: https://codereview.chromium.org/2684993002
Cr-Commit-Position: refs/heads/master@{#43290}
... which is used for initializing properties with non compile time values.
Currently we use StoreOwnIC only for storing properties that already exist
in the boilerplate therefore we can reuse StoreIC dispatcher.
The proper StoreOwnIC dispatcher will be implemented in a separate CL.
BUG=v8:5495, v8:4414
Change-Id: I9c33fdb8499ec5be2c7fce1ecb6ce7aa285e5844
Reviewed-on: https://chromium-review.googlesource.com/443588
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43285}
Add `ValueSerializer::SetTreatArrayBufferViewsAsHostObjects()` which
instructs the `ValueSerializer` to treat ArrayBufferView objects as
host objects.
BUG=v8:5926
Review-Url: https://codereview.chromium.org/2696133007
Cr-Commit-Position: refs/heads/master@{#43281}
https://crrev.com/2500363002 updated FunctionTemplate::HasInstance to
follow the hidden prototype chain of a global proxy to the global
object. However, remote contexts don't have a global object to check;
instead, teach the instance check knows about the conventions of
global proxy setup and have it also check the constructor's prototype.
Similarly, also teach Object::FindInstanceInPrototypeChain about the
unusual conventions for remote contexts.
BUG=527190
Review-Url: https://codereview.chromium.org/2698683003
Cr-Commit-Position: refs/heads/master@{#43263}
Before this patch, the registers needed for bytecode dispatch in interpreter
handlers were inconsistently stored in the interpreter frame and/or kept in
values that remained live across calls.
After this patch, these registers are explicitly reloaded after calls, making it
possible to elide the spills of those registers before the call in many cases.
Some highlights from the CL:
* Added methods to the CSA and InterpreterAssembler to efficiently store and
load Smis values and Smi interpreter registers on x64 without explicit
tagging/untagging.
* Created Variables for all of the interpreter-internal values that need to be
reloaded before bytecode dispatch at the end of an interpreter handler.
* The bytecode offset can be written out early in a handler by marking it
has having a call along it's critical path. By moving this early in a
handler, it becomes possible to use memory operands for pushes used to
marshall parameters when making calls.
Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
Reviewed-on: https://chromium-review.googlesource.com/442566
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43260}
The serializer won't ever write a more complex object. Not validating this
allows other things to be used as keys, and converted to string when the
property set actually occurs. It turns out this gives an opportunity to trigger
OOM by giving an object a key which is a very large sparse array (whose string
representation is very large).
This case is now rejected by the deserializer.
BUG=chromium:686511
Review-Url: https://codereview.chromium.org/2697023002
Cr-Commit-Position: refs/heads/master@{#43249}
This handles arithmetic addition operations during the early type-hint
lowering (i.e. during graph construction). The string addition case is
still handled by {JSTypedLowering} as it needs static type information.
R=bmeurer@chromium.org
Change-Id: I9df47dfc5bf7613c51f6d803ab43d5d3f6c21be8
Reviewed-on: https://chromium-review.googlesource.com/443185
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43235}
This handles all arithmetic binary operations except addition during the
early type-hint lowering (i.e. during graph construction). We still use
static type information to potentially further reduce the speculative
operations down to pure operations during the typed lowering phase.
R=bmeurer@chromium.org
Change-Id: I8b93fd7c46ec8e5b81234a49624d503520c3d082
Reviewed-on: https://chromium-review.googlesource.com/443105
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43218}
This allows part of typed lowering that is solely based on type-hints to
run as part of the graph construction. The lowering in question does not
inspect types and hence doesn't require the typer to have run before. We
insert the speculative simplied-level operations in favor of the generic
JavaScript-level variants.
R=bmeurer@chromium.org
Change-Id: I5f0549fc1e4ff607622ee9059e6232a32f77db2e
Reviewed-on: https://chromium-review.googlesource.com/442584
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43208}
If a job was already enqueued, EnqueueAndStep would still step the job one
more step. However, since it didn't take the job out of the
pending_background_jobs pool, the job could get picked up by a background
thread which would try to step it, but it the job is now at a step which
can't be run on the background.
BUG=v8:5203,chromium:685515
Change-Id: I2cee2a33625ba455aca49a8037601be9ff8bb73f
Reviewed-on: https://chromium-review.googlesource.com/441084
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43121}
Don't block on inner function compilation before competing outer function
compilation. Instead wait for the compilation to complete when the function
is called.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2686673002
Cr-Commit-Position: refs/heads/master@{#43116}
Removes handles from bytecode generation, instead storing
un-internalized AstValues (and other, similar values such as Scopes and
AstRawStrings) in the constant array builder.
This will allow us in the future to generate the bytecode before
internalizing the AST.
BUG=v8:5832
Change-Id: I3b8be8f7329a484eb1e5d12808b001d3475239da
Reviewed-on: https://chromium-review.googlesource.com/439326
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43115}
When running main-thread compiler-dispatcher jobs, ensure that we enter the
correct Context. Also adds a test for compiling an extension in the compiler
dispatcher to ensure that idle tasks enter the correct context before
finalizing the compilation.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2679193004
Cr-Commit-Position: refs/heads/master@{#43111}
This introduces new maps to track whether we have created at most one
closure. If we have created just one closure, Turbofan will
specialize the code to its context.
Review-Url: https://codereview.chromium.org/2680313002
Cr-Commit-Position: refs/heads/master@{#43108}
In order to compile eager inner functions on a background thread we need to
keep the handles created during parsing and scope analysis alive until the
background compilation is complete. In order to do that, we allocate the
handles in a deferred handle scope and keep the deferred handles alive with
a shared_ptr in the ParseInfo and CompileInfo respectively.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2650883002
Cr-Commit-Position: refs/heads/master@{#43107}
Reason for revert:
Issue on arm64:
https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim/builds/5752
Original issue's description:
> [Compiler] Enable handles created during parsing and scope analysis to be deferred.
>
> In order to compile eager inner functions on a background thread we need to
> keep the handles created during parsing and scope analysis alive until the
> background compilation is complete. In order to do that, we allocate the
> handles in a deferred handle scope and keep the deferred handles alive with
> a shared_ptr in the ParseInfo and CompileInfo respectively.
>
> BUG=v8:5203
>
> Review-Url: https://codereview.chromium.org/2650883002
> Cr-Commit-Position: refs/heads/master@{#43091}
> Committed: 9346cd9b4cTBR=marja@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2687973003
Cr-Commit-Position: refs/heads/master@{#43093}
In order to compile eager inner functions on a background thread we need to
keep the handles created during parsing and scope analysis alive until the
background compilation is complete. In order to do that, we allocate the
handles in a deferred handle scope and keep the deferred handles alive with
a shared_ptr in the ParseInfo and CompileInfo respectively.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2650883002
Cr-Commit-Position: refs/heads/master@{#43091}
In order to allow parallel compilation of eager inner functions, we need to
seperate the zone used for parsing (which will be shared between all the
parallel compile jobs) and the zone used for compilation. This CL changes
CompilationInfo to require a zone (which can be different from the zone in
ParseInfo). We then seal the ParseInfo zone after parsing and analysis is done
to prevent any further allocation in that zone, so that it can be shared
(read-only) with the parallel compile jobs.
BUG=v8:5203
Review-Url: https://codereview.chromium.org/2645403002
Cr-Commit-Position: refs/heads/master@{#43089}
arguments.h is one of the headers including objects-inl.h. Files needing
objects-inl.h used to innocently pull in debug.h, so that needs to be fixed now
too.
BUG=v8:5294
R=mstarzinger@chromium.org
Change-Id: I8ce671c533ed757103ef9a3b0bf0a0509230fdd8
Reviewed-on: https://chromium-review.googlesource.com/439287
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43054}
Since the empty string is canonical HeapObject now, we can use
this fact to optimize
- strict equality comparisons with the empty string to a
simple ReferenceEqual operation, and
- optimize ToBoolean to avoid instance type checks completely.
Drive-by-fix: Allow InternalizedString for Type::HeapConstant
in the type system. This is safe, since InternalizedStrings
can be compared to other heap constants by reference (except
for non-InternalizedStrings, which are excluded from the
HeapConstant type).
BUG=v8:5267
R=yangguo@chromium.org
Review-Url: https://codereview.chromium.org/2681273002
Cr-Commit-Position: refs/heads/master@{#43050}
Without doing this, a JSMessageObject can be kept alive by the isolate, which
in turn keeps the context alive, until the message is cleared.
BUG=v8:5941
Review-Url: https://codereview.chromium.org/2675203005
Cr-Commit-Position: refs/heads/master@{#43043}
Arm64 compiles "x +_64 (y >> shift)" into a single instruction if
"shift" is a constant. The code generator expects that "shift" is a
32 bit constant. however, TurboFan can also pass in a 64 bit constant,
which caused a crash in the code generator.
With this CL we cast the constant of TurboFan to an int in the
instruction selector and thereby satisfy the assumption of the code
generator. This should be correct since the code generator anyways cast
the "shift" to an int5 or int6 eventually.
R=v8-arm-ports@googlegroups.com
BUG=v8:5923
Review-Url: https://codereview.chromium.org/2669203005
Cr-Commit-Position: refs/heads/master@{#43036}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Reland: [Parse] ParseInfo owns the parsing Zone. (patchset #7 id:140001 of https://codereview.chromium.org/2632123006/ )
>
> Reason for revert:
> Speculative revert because of revert needed for https://codereview.chromium.org/2632123006
>
> Original issue's description:
> > Reland: [Parse] ParseInfo owns the parsing Zone.
> >
> > Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> > in preperation for enabling background compilation jobs for inner functions
> > share the AST in the outer-function's parse zone memory (read-only), with the
> > and zone being released when all compilation jobs have completed.
> >
> > BUG=v8:5203,v8:5215
> >
> > Review-Url: https://codereview.chromium.org/2632123006
> > Cr-Original-Commit-Position: refs/heads/master@{#42993}
> > Committed: 14fb337200
> > Review-Url: https://codereview.chromium.org/2632123006
> > Cr-Commit-Position: refs/heads/master@{#42996}
> > Committed: 9e7d5a6065
>
> TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2683733002
> Cr-Commit-Position: refs/heads/master@{#43008}
> Committed: 9fe08ec067TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2679303003
Cr-Commit-Position: refs/heads/master@{#43015}
Reason for revert:
False alarm, bot hiccup
Original issue's description:
> Revert of Thread maybe-assigned through the bytecodes. (patchset #5 id:80001 of https://codereview.chromium.org/2655733003/ )
>
> Reason for revert:
> needed for properly reverting f3ae5ccf57
>
> Original issue's description:
> > Thread maybe-assigned through the bytecodes.
> >
> > This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> > bytecodes, which are emitted when reading from never-assigned context slot.
> >
> > There is a subtlety here: the slot are not immutable, the meaning is
> > actually undefined-or-hole-or-immutable.
> >
> > Review-Url: https://codereview.chromium.org/2655733003
> > Cr-Commit-Position: refs/heads/master@{#43000}
> > Committed: 17c2dd3886
>
> TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Review-Url: https://codereview.chromium.org/2680923003
> Cr-Commit-Position: refs/heads/master@{#43011}
> Committed: ece4e54a31TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2679953003
Cr-Commit-Position: refs/heads/master@{#43012}
Reason for revert:
needed for properly reverting f3ae5ccf57
Original issue's description:
> Thread maybe-assigned through the bytecodes.
>
> This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
> bytecodes, which are emitted when reading from never-assigned context slot.
>
> There is a subtlety here: the slot are not immutable, the meaning is
> actually undefined-or-hole-or-immutable.
>
> Review-Url: https://codereview.chromium.org/2655733003
> Cr-Commit-Position: refs/heads/master@{#43000}
> Committed: 17c2dd3886TBR=rmcilroy@chromium.org,bmeurer@chromium.org,neis@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2680923003
Cr-Commit-Position: refs/heads/master@{#43011}
Reason for revert:
Speculative revert because of revert needed for https://codereview.chromium.org/2632123006
Original issue's description:
> Reland: [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Original-Commit-Position: refs/heads/master@{#42993}
> Committed: 14fb337200
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42996}
> Committed: 9e7d5a6065TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2683733002
Cr-Commit-Position: refs/heads/master@{#43008}
This introduces LoadImmutableContextSlot and LoadImmutableCurrentContextSlot
bytecodes, which are emitted when reading from never-assigned context slot.
There is a subtlety here: the slot are not immutable, the meaning is
actually undefined-or-hole-or-immutable.
Review-Url: https://codereview.chromium.org/2655733003
Cr-Commit-Position: refs/heads/master@{#43000}
... and TypeFeedbackMetadata to FeedbackMetadata.
BUG=
Change-Id: I2556d1c2a8f37b8cf3d532cc98d973b6dc7e9e6c
Reviewed-on: https://chromium-review.googlesource.com/439244
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#42999}
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
in preperation for enabling background compilation jobs for inner functions
share the AST in the outer-function's parse zone memory (read-only), with the
and zone being released when all compilation jobs have completed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2632123006
Cr-Original-Commit-Position: refs/heads/master@{#42993}
Committed: 14fb337200
Review-Url: https://codereview.chromium.org/2632123006
Cr-Commit-Position: refs/heads/master@{#42996}
Reason for revert:
doesn't compile on ToT
Original issue's description:
> Reland: [Parse] ParseInfo owns the parsing Zone.
>
> Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
> in preperation for enabling background compilation jobs for inner functions
> share the AST in the outer-function's parse zone memory (read-only), with the
> and zone being released when all compilation jobs have completed.
>
> BUG=v8:5203,v8:5215
>
> Review-Url: https://codereview.chromium.org/2632123006
> Cr-Commit-Position: refs/heads/master@{#42993}
> Committed: 14fb337200TBR=marja@chromium.org,mstarzinger@chromium.org,ahaas@chromium.org,verwaest@chromium.org,rmcilroy@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2685543003
Cr-Commit-Position: refs/heads/master@{#42994}
Moves ownership of the parsing Zone to ParseInfo with a shared_ptr. This is
in preperation for enabling background compilation jobs for inner functions
share the AST in the outer-function's parse zone memory (read-only), with the
and zone being released when all compilation jobs have completed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2632123006
Cr-Commit-Position: refs/heads/master@{#42993}
This correctly marks the {JSCreate} operator as potentially throwing,
since it might trigger a property access of the 'prototype' property
during instantiation. This is observable, can throw (not kNoThrow),
might have side-effects (not kNoWrite), or even trigger a lazy deopt
event (not kNoDeopt). The inlining logic has been adapted to wire up
control projections accordingly.
Note that this does not yet take care of the "after" frame-state which
is associated with the {JSCreate} node introduced by the inliner. We
still might re-evaluate the property access upon lazy deoptimization.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-5638
BUG=v8:5638
Review-Url: https://codereview.chromium.org/2671203003
Cr-Commit-Position: refs/heads/master@{#42981}
TypeFeedbackVectors are strongly rooted by a closure. However, in modern
JavaScript closures are created and abandoned more freely. An important
closure may not be present in the root-set at time of garbage collection,
even though we've cached optimized code and use it regularly. For
example, consider leaf functions in an event dispatching system. They may
well be "hot," but tragically non-present when we collect the heap.
Until now, we've relied on a weak root to cache the feedback vector in
this case. Since there is no way to signal intent or relative importance,
this weak root is as susceptible to clearing as any other weak root at
garbage collection time.
Meanwhile, the feedback vector has become more important. All of our
ICs store their data there. Literal and regex boilerplates are stored there.
If we lose the vector, then we not only lose optimized code built from
it, we also lose the very feedback which allowed us to create that optimized
code. Therefore it's vital to express that dependency through the root
set.
This CL does this by creating a strong link to a feedback
vector at the instantiation site of the function closure.
This instantiation site is in the code and feedback vector
of the outer closure.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2674593003
Cr-Commit-Position: refs/heads/master@{#42953}
First discovery by the names section fuzzer I think. During the decoding
of the names of locals only ok() of the outer decoder was checked, not
the ok() of the actual names section decoder.
R=tizer@chromium.org
BUG=chromium:684855
Review-Url: https://codereview.chromium.org/2648383007
Cr-Commit-Position: refs/heads/master@{#42880}
This avoids the need to pull in the UTF-8 encoding code from the public API,
and allows it to take advantage of any supported way that i::String can be
encoded (one- or two-byte).
Backward compatibility is maintained, but this is the behavior beginning
with this version.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2665653004
Cr-Commit-Position: refs/heads/master@{#42872}
The int64-lowering only lowered store instructions with a word64 store
representation. For all other stores the default lowering applied. The
default lowering replaces all input nodes with both their replacement
nodes, which can change the number of input nodes of the lowered node.
In WebAssembly there exist stores which take an I64 input and store it
with a different representation, e.g. I32. In TurboFan this translates
to a store node with word32 store representation and a word64 value
input. The default lowering replaces the word64 value input to become
two word32 value inputs, which makes the number of inputs of the store
node invalid. This CL discards the high word replacement of the value
input so that the number of input nodes of a store node does not change
in the default lowering.
R=titzer@chromium.orgCC=rossberg@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2668023004
Cr-Commit-Position: refs/heads/master@{#42860}
Rename to Construct and ConstructWithSpread, to match the names of
the JSOperators used.
Unfortunately, I can't find a way for auto-formatting to stay happy unless we
change the indentation for the whole BYTECODE_LIST macro.
Review-Url: https://codereview.chromium.org/2663963003
Cr-Commit-Position: refs/heads/master@{#42840}
Dealing with this case requires a wire format change. It is possible that an
element can be absent even in an array where the dense format was chosen
(because the array initially had no holes), if the elements are modified while
they are being serialized. In this case, a new tag for the "hole" is emitted.
The logic to treat undefined in dense arrays as an absent property is restricted
to versions of the wire format that this tag did not exist.
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2660093002
Cr-Original-Commit-Position: refs/heads/master@{#42784}
Committed: dc85f4c833
Review-Url: https://codereview.chromium.org/2660093002
Cr-Commit-Position: refs/heads/master@{#42800}
Reason for revert:
Seems to break layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/13146https://github.com/v8/v8/wiki/Blink-layout-tests
Original issue's description:
> ValueSerializer: Distinguish between 'undefined' and an absent property.
>
> Dealing with this case requires a wire format change. It is possible that an
> element can be absent even in an array where the dense format was chosen
> (because the array initially had no holes), if the elements are modified while
> they are being serialized. In this case, a new tag for the "hole" is emitted.
>
> The logic to treat undefined in dense arrays as an absent property is restricted
> to versions of the wire format that this tag did not exist.
>
> BUG=chromium:686159,chromium:665820
>
> Review-Url: https://codereview.chromium.org/2660093002
> Cr-Commit-Position: refs/heads/master@{#42784}
> Committed: dc85f4c833TBR=jkummerow@chromium.org,jbroman@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2667553003
Cr-Commit-Position: refs/heads/master@{#42788}
Dealing with this case requires a wire format change. It is possible that an
element can be absent even in an array where the dense format was chosen
(because the array initially had no holes), if the elements are modified while
they are being serialized. In this case, a new tag for the "hole" is emitted.
The logic to treat undefined in dense arrays as an absent property is restricted
to versions of the wire format that this tag did not exist.
BUG=chromium:686159,chromium:665820
Review-Url: https://codereview.chromium.org/2660093002
Cr-Commit-Position: refs/heads/master@{#42784}
They have the same lifetime. It's a match!
Both structures are native context dependent and dealt with (creation,
clearing, gathering feedback) at the same time. By treating the spaces used
for literal boilerplates as feedback vector slots, we no longer have to keep
track of the materialized literal count elsewhere.
A follow-on CL removes even more parser infrastructure related to this count.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2655853010
Cr-Commit-Position: refs/heads/master@{#42771}
memcpy is faster than UTF-8 encoding/decoding. This yields 10-20% wins on
serializing and deserializing long ASCII strings, according to
blink_perf.bindings -- and these are already in a fast path where the entire
string is known to be ASCII (but this has to be checked). The win may be
larger for strings in Latin-1 but not ASCII (though I suspect this is an
uncommon case).
A change is also made to make ValueSerializerTest.EncodeTwoByteStringUsesPadding
survive wire format version number changes.
This is the first of a series of wire format changes from the previous Blink
format. The deserializer continues to be able to read the old format, but
Chromium M56 will no longer be able to read the messages written by this, in M58.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2658793004
Cr-Commit-Position: refs/heads/master@{#42753}
Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2611313002
Cr-Commit-Position: refs/heads/master@{#42667}
Since JumpLoop is always backwards, and other jumps are always forwards,
we can store the jump offset as an always positive integer and decide on
the jump direction based on the bytecode. This will save a small amount
of space for large-ish for loops (>128 bytecodes).
Review-Url: https://codereview.chromium.org/2641443002
Cr-Commit-Position: refs/heads/master@{#42638}
We can share almost all of the architecture-specific builtin code with super-call-with-spread.
Info to port-writers: The code in CheckSpreadAndPushToStack has changed slightly from what was in Generate_ConstructWithSpread, in that we take the length of the spreaded parameters from the JSArray rather than the FixedArray backing store.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2649143002
Cr-Commit-Position: refs/heads/master@{#42632}
In this particular case, we just did a (lhs)op(rhs), ignoring the case
that lhs and rhs might have different signedness.
This CL changes that to use the proper Cmp##op##Impl implementation,
which does two comparisions for signed-vs-unsigned checks, avoiding
compiler errors.
R=ishell@chromium.org
Review-Url: https://codereview.chromium.org/2642383002
Cr-Commit-Position: refs/heads/master@{#42566}
This patch adds destructor to ValueSerializerTest test fixture class
which reset unhandled scheduled exceptions thrown from the current test.
In some cases unhandled scheduled exceptions from current test (eg.
from one test from ValueSerializerTestWithWasm test case) produce that
Context::New(isolate()) from next test's constructor returns NULL.
This error is easily reproduced when unittest file (compiled for ARM or
MIPS simulator) is directly executed (not by tools/run_tests.py script),
so all tests are executed together. When the script is used, each test
from ValueSerializerTestWithWasm test case is separately executed and
unhandled exception from one test doesn't efect to another test from
the same test case.
BUG=
Review-Url: https://codereview.chromium.org/2644083002
Cr-Commit-Position: refs/heads/master@{#42547}
Clang just got more strict about unused lambda captures,
and that requires us to clean all places with this issue
across all the Chromium code base. This CL fixes all such
cases in V8.
BUG=chromium:681136
Review-Url: https://codereview.chromium.org/2646553002
Cr-Commit-Position: refs/heads/master@{#42523}
Reason for revert:
Causes a few bugs caught by clusterfuzz.
Original issue's description:
> [Ignition/turbo] Add a CallWithSpread bytecode.
>
> Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser.
>
> BUG=v8:5511
>
> Review-Url: https://codereview.chromium.org/2629363002
> Cr-Commit-Position: refs/heads/master@{#42455}
> Committed: 4bae43471dTBR=bmeurer@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2642843002
Cr-Commit-Position: refs/heads/master@{#42470}
Also, emit a NewWithSpread bytecode for CallNew AST nodes where possible, rather than desugaring in the parser.
BUG=v8:5511
Review-Url: https://codereview.chromium.org/2629363002
Cr-Commit-Position: refs/heads/master@{#42455}
The existing implementation assumes that return nodes have exactly one
real value input. This assumption does not hold for WebAssembly. To
avoid incorrect behavior, this CL turns of the reduction of returns
with a value input count != 1.
R=titzer@chromium.org, mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2638053002
Cr-Commit-Position: refs/heads/master@{#42425}
Enable enqueueing of eager inner function compilation onto the compiler
dispatcher. This enables these tasks to be performed in parallel to
compilation of the outer functio (only for Ignition functions).
We currently synchronize to ensure all inner function compilations
are complete before executing the outer function - future work will
allow outer function execution to happenin parallel to inner function
compilation.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2611313002
Cr-Commit-Position: refs/heads/master@{#42413}
KillFields of an object should remove its cache from all the fields.
Currently, the cache in the front field is kept which is not expected.
This patch fixes it.
Review-Url: https://codereview.chromium.org/2618273002
Cr-Commit-Position: refs/heads/master@{#42388}
Moves constant element/property array building to be deferred for
igition and on-demand for the other compilers, and splits off the
object/array literal depth/flag initialisation from the array building.
BUG=v8:5832
Review-Url: https://codereview.chromium.org/2625873009
Cr-Commit-Position: refs/heads/master@{#42362}
This puts lowering of {JSCreateClosure} operations behind a flag. For
now the benefit of inline allocating such closures is negligible, it
does increase code size, and breaks in combination with inlining based
on {SharedFunctionInfo}.
R=jarin@chromium.org
BUG=v8:2206
Review-Url: https://codereview.chromium.org/2636493002
Cr-Commit-Position: refs/heads/master@{#42331}
Reason for revert:
OK, the failure really does seem to be due to this patch: It triggers Clang to crash
FAILED: obj/test/unittests/unittests/function-body-decoder-unittest.obj
E:\b\build\slave\cache\cipd\goma/gomacc.exe ../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo /showIncludes /FC @obj/test/unittests/unittests/function-body-decoder-unittest.obj.rsp /c ../../test/unittests/wasm/function-body-decoder-unittest.cc /Foobj/test/unittests/unittests/function-body-decoder-unittest.obj /Fd"obj/test/unittests/unittests_cc.pdb"
Assertion failed: (NumGaps == 0 || Bias < MaxDefRange) && "large ranges should not have gaps", file E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\lib\MC\MCCodeView.cpp, line 531
Wrote crash dump file "C:\Users\CHROME~2\AppData\Local\Temp\goma_temp.5068\clang-cl.exe-563144.dmp"
Let's leave it out for now.
Original issue's description:
> Reland of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #1 id:1 of https://codereview.chromium.org/2628883006/ )
>
> Reason for revert:
> Try a reland; this might not have been the source of tree-closing.
>
> Original issue's description:
> > Revert of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #3 id:40001 of https://codereview.chromium.org/2630553002/ )
> >
> > Reason for revert:
> > Caused tree to close by failing compilation:
> >
> > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/4451
> >
> > Original issue's description:
> > > [wasm] Enforce that function bodies end with the \"end\" opcode.
> > >
> > > R=rossberg@chromium.org
> > > BUG=chromium:575167
> > >
> > > Review-Url: https://codereview.chromium.org/2630553002
> > > Cr-Commit-Position: refs/heads/master@{#42286}
> > > Committed: fcc6e85ec6
> >
> > TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=chromium:575167
> >
> > Review-Url: https://codereview.chromium.org/2628883006
> > Cr-Commit-Position: refs/heads/master@{#42287}
> > Committed: 1d32a3989b
>
> TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:575167
>
> Review-Url: https://codereview.chromium.org/2628203003
> Cr-Commit-Position: refs/heads/master@{#42296}
> Committed: e539bd8e0eTBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2633583002
Cr-Commit-Position: refs/heads/master@{#42298}
Reason for revert:
Try a reland; this might not have been the source of tree-closing.
Original issue's description:
> Revert of [wasm] Enforce that function bodies end with the \"end\" opcode. (patchset #3 id:40001 of https://codereview.chromium.org/2630553002/ )
>
> Reason for revert:
> Caused tree to close by failing compilation:
>
> https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/4451
>
> Original issue's description:
> > [wasm] Enforce that function bodies end with the \"end\" opcode.
> >
> > R=rossberg@chromium.org
> > BUG=chromium:575167
> >
> > Review-Url: https://codereview.chromium.org/2630553002
> > Cr-Commit-Position: refs/heads/master@{#42286}
> > Committed: fcc6e85ec6
>
> TBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=chromium:575167
>
> Review-Url: https://codereview.chromium.org/2628883006
> Cr-Commit-Position: refs/heads/master@{#42287}
> Committed: 1d32a3989bTBR=mtrofin@chromium.org,rossberg@chromium.org,jbroman@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:575167
Review-Url: https://codereview.chromium.org/2628203003
Cr-Commit-Position: refs/heads/master@{#42296}
This CL modifies the ast-numbering phase to collect function literals which
should be compiled eagerly. This is then used to eagerly compile the inner
functions before compiling the outer function. This will be used to queue
compilation jobs on the CompilerDispatcher in a later CL.
This CL moves the compilation of eager inner functions out of the
GetSharedFunctionInfo function and instead compiles them explicitly. This
simplifies GetSharedFunctionInfo and also means there is no need to pass a
LazyCompilationMode to the function, so this concept has been removed.
BUG=v8:5203,v8:5215
Review-Url: https://codereview.chromium.org/2618553004
Cr-Commit-Position: refs/heads/master@{#42221}
This changes the NewClosure interface descriptor, but ignores
the additional vector/slot arguments for now. The feedback vector
gets larger, as it holds a space for each literal array. A follow-on
CL will constructively use this space.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2614373002
Cr-Commit-Position: refs/heads/master@{#42146}
GCC4.8.5 on s390 emits warning "array subscript is above array bounds"
for line "code[pos + 1] = kLocalVoid;". The warning seems to be
correct because code[sizeof(code)] should be out of bounds.
I'm suggesting to run the loop till "sizeof(code) - 1" which GCC(4.8.5)
agrees with. Although this means the last byte is missed, but it should
be safe to do since the last few bytes are "0xb" (kExprEnd) and the
offending statement is only run when byte=kExprBlock.
R=titzer@chromium.org, mstarzinger@chromium.org, bradnelson@chromium.org
BUG=
LOG=N
Review-Url: https://codereview.chromium.org/2619063002
Cr-Commit-Position: refs/heads/master@{#42145}
Downside: this adds all kinds of weird includes in the .cc files.
(See design doc linked in the bug.)
BUG=v8:5402
Review-Url: https://codereview.chromium.org/2622503002
Cr-Commit-Position: refs/heads/master@{#42140}
Separated:
- decoding of locals
- loop assignment analysis
- determination of opcode length
as statics that work on a Decoder. Neither need the context of a
Module, and were used in scenarios where one wasn't available either.
Changed BodyLocalDecls to match the usecases for the type. In all but
one (a printer), we want the list (in order of declaration, with
repetitions) of types of locals.
Removed a now-unnecessary constructor for the WasmFullDecoder.
BUG=
Review-Url: https://codereview.chromium.org/2610813009
Cr-Commit-Position: refs/heads/master@{#42115}
Add a more efficient encoding for state values that have a large number of
optimized-out inputs.
Review-Url: https://codereview.chromium.org/2509623002
Cr-Commit-Position: refs/heads/master@{#42088}
Add a feedback vector slot for computed property names in object
and class literals. Introduce new slot kind for storing
computed property names.
Change StaDataPropertyInLiteral to use the accumulator (again), so
we don't exceed Bytecodes::kMaxOperands.
We assume that most computed property names are
symbols. Therefore we should see performance
improvements, even if we deal with monomorphic ICs only.
This CL only collects feedback but does not use
it in Reduce() yet.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2587393006
Cr-Commit-Position: refs/heads/master@{#42082}
This CL simplifies the relation between the wasm graph builder, the
wasm decoder, and the wasm module they work on.
BUG=
Review-Url: https://codereview.chromium.org/2612643002
Cr-Commit-Position: refs/heads/master@{#42056}
Hook up TurboFan with the existing field type tracking machinery to
eliminate redundant map checks on the results of LoadField operators.
The store side is already implemented in TurboFan for quite some time,
this just adds the load part.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2604393002
Cr-Commit-Position: refs/heads/master@{#42015}
We need to report cached wrappers within v8 to the embedder after each atomic
phase of v8 marking because the embedder can invalidate the wrappers in-between
v8 marking steps.
E.g., in Chrome, a conservative GC might need to wipe dead wrappables from
the wrapper tracing marking deque.
BUG=chromium:676700, chromium:468240
Review-Url: https://codereview.chromium.org/2610563002
Cr-Commit-Position: refs/heads/master@{#42011}
... and add explicit CallPrologue/CallEpilogue callbacks to CodeAssemblerState instead.
This will allow IntepreterAssembler to use any other helper assembler.
TBR=rmcilroy@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2600183004
Cr-Commit-Position: refs/heads/master@{#41973}
Reland 0cf5623220
The original patch got reverted because testing RegisterConfiguration was
overwritten by turbofan RegisterConfiguration. This caused some test cases not being
properly tested. The new patch uses correct RegisterConfiguration.
Original commit message:
Test InstructionSequenceTest has been initialized with a testing RegisterConfiguration
instance defined in instruction-sequence-unittest.h, whereas class ExplicitOperand which
is being tested used RegisterConfiguration from instruction.cc. In case these two
instances are different, the tests would fail. The issue is fixed by using the same
instance of RegisterConfiguration both for test code and code under test.
Additionally, the tests in register-allocator-unittest.cc use hardcoded values
for register and begin failing is the hardcoded register is not available for
allocation. Fix by forcing the use of allocatable registers only.
TEST=unittests.MoveOptimizerTest.RemovesRedundantExplicit,unittests.RegisterAllocatorTest.SpillPhi
BUG=
Review-Url: https://codereview.chromium.org/2595293002
Cr-Commit-Position: refs/heads/master@{#41938}
Reason for revert:
Speculative revert because of blocked roll: https://codereview.chromium.org/2596013002/
Original issue's description:
> [TypeFeedbackVector] Root literal arrays in function literals slots
>
> Literal arrays and feedback vectors for a function can be garbage
> collected if we don't have a rooted closure for the function, which
> happens often. It's expensive to come back from this (recreating
> boilerplates and gathering feedback again), and the cost is
> disproportionate if the function was inlined into optimized code.
>
> To guard against losing these arrays when we need them, we'll now
> create literal arrays when creating the feedback vector for the outer
> closure, and root them strongly in that vector.
>
> BUG=v8:5456
>
> Review-Url: https://codereview.chromium.org/2504153002
> Cr-Commit-Position: refs/heads/master@{#41893}
> Committed: 93df094081TBR=bmeurer@chromium.org,mlippautz@chromium.org,mvstanton@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2597163002
Cr-Commit-Position: refs/heads/master@{#41917}
Reason for revert:
speculative revert: https://codereview.chromium.org/2596013002/
Original issue's description:
> [regexp] Remove IsRegExp intrinsic
>
> The two remaining uses of this intrinsic in debug.js and mirrors.js now
> simply rely on the runtime function.
>
> BUG=v8:5339
>
> Review-Url: https://codereview.chromium.org/2591923003
> Cr-Commit-Position: refs/heads/master@{#41892}
> Committed: c9cb94a06fTBR=bmeurer@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2592383002
Cr-Commit-Position: refs/heads/master@{#41915}
Literal arrays and feedback vectors for a function can be garbage
collected if we don't have a rooted closure for the function, which
happens often. It's expensive to come back from this (recreating
boilerplates and gathering feedback again), and the cost is
disproportionate if the function was inlined into optimized code.
To guard against losing these arrays when we need them, we'll now
create literal arrays when creating the feedback vector for the outer
closure, and root them strongly in that vector.
BUG=v8:5456
Review-Url: https://codereview.chromium.org/2504153002
Cr-Commit-Position: refs/heads/master@{#41893}
The two remaining uses of this intrinsic in debug.js and mirrors.js now
simply rely on the runtime function.
BUG=v8:5339
Review-Url: https://codereview.chromium.org/2591923003
Cr-Commit-Position: refs/heads/master@{#41892}
This is more renaming work to comply with the naming in the public
design repository. E.g. types are called "value types" and we no longer
refer to ASTs.
R=clemensh@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2594993002
Cr-Commit-Position: refs/heads/master@{#41891}
eval() may introduce a scope which needs to be represented as a context at
runtime, e.g.,
eval('var x; let y; ()=>y')
introduces a variable y which needs to have a context allocated for it. However,
when traversing upwards to find the declaration context for a variable which leaks,
as the declaration of x does above, this context has to be understood to not be
a declaration context in sloppy mode.
This patch makes that distinction by introducing a different map for eval-introduced
contexts. A dynamic search for the appropriate context will continue past an eval
context to find the appropriate context. Marking contexts as eval contexts rather
than function contexts required updates in each compiler backend.
BUG=v8:5295, chromium:648719
Review-Url: https://codereview.chromium.org/2435023002
Cr-Commit-Position: refs/heads/master@{#41869}
We have the BytecodeIterator with next() and has_next() methods, and
pc_offset() and current() accessors.
This CL adds an interface to iterate over the opcodes or offsets in a
C++ foreach loop.
R=titzer@chromium.org
Review-Url: https://codereview.chromium.org/2587143002
Cr-Commit-Position: refs/heads/master@{#41851}
Encode the PropertyAttribute and whether the function
names must be set as a flag instead of setting two registers.
BUG=v8:5624
Review-Url: https://codereview.chromium.org/2586463002
Cr-Commit-Position: refs/heads/master@{#41812}
STRUCT_LIST and INSTANCE_TYPE_LIST are now forced to have the same order
as the InstanceType enum.
Drive-by-fix 1: Move type check and cast functions closer together in objects-inl.h
Drive-by-fix 2: Remove unused instance types SIGNATURE_INFO_TYPE and TYPE_SWITCH_INFO_TYPE.
BUG=
Review-Url: https://codereview.chromium.org/2578573002
Cr-Commit-Position: refs/heads/master@{#41804}
This is so that a NotSuperConstructor error is thrown before evaluating the
arguments to the super constructor. Besides updating the runtime function, a
new bytecode GetSuperConstructor is introduced.
BUG=v8:5336
Review-Url: https://codereview.chromium.org/2504553003
Cr-Commit-Position: refs/heads/master@{#41788}
There are subtle test expectations/nuances that are easy to break.
BUG=
Review-Url: https://codereview.chromium.org/2585583006
Cr-Commit-Position: refs/heads/master@{#41778}
Reason for revert:
This change rendered InstructionSequenceTest::SetNumRegs ineffectual, thus
loosening the tests that were using that API to ensure correct register
allocation under intentionally constrained setups.
For the problem stated in this CL, a solution needs to continue supporting the
intentionally set-up test configuration.
Original issue's description:
> MIPS: Fix bad RegisterConfiguration usage in InstructionSequence unit tests.
>
> Test InstructionSequenceTest has been initialized with a testing RegisterConfiguration
> instance defined in instruction-sequence-unittest.h, whereas class ExplicitOperand which
> is being tested used RegisterConfiguration from instruction.cc. In case these two
> instances are different, the tests would fail. The issue is fixed by using the same
> instance of RegisterConfiguration both for test code and code under test.
>
> Additionally, the tests in register-allocator-unittest.cc use hardcoded values
> for register and begin failing is the hardcoded register is not available for
> allocation. Fix by forcing the use of allocatable registers only.
>
> TEST=unittests.MoveOptimizerTest.RemovesRedundantExplicit,unittests.RegisterAllocatorTest.SpillPhi
> BUG=
>
> Committed: https://crrev.com/0cf56232209d4c9c669b8426680de18806f6c29a
> Cr-Commit-Position: refs/heads/master@{#40862}
TBR=dcarney@chromium.org,bmeurer@chromium.org,mstarzinger@chromium.org,vogelheim@chromium.org,titzer@chromium.org,ivica.bogosavljevic@imgtec.com
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=
Review-Url: https://codereview.chromium.org/2587593002
Cr-Commit-Position: refs/heads/master@{#41777}
Transform LdaNull/LdaUndefined followed by StrictEquality to TestNull/TestUndefined.
This would avoid a call to the compare IC. In the bytecode-graph builder these are
mapped to StrictEqual javascript operator. When reducing this operator, we already
optimize the cases for null/undefined.
BUG=v8:4280
Review-Url: https://codereview.chromium.org/2554723004
Cr-Commit-Position: refs/heads/master@{#41768}
This introduces an explicit struct for the communication channel between
the {ArrayLiteral} AST node and the corresponding runtime methods. Those
methods take a pair of {ElementsKind} as well as an array (can either be
a FixedArray or a FixedDoubleArray) of constant values.
For bonus points it also reduces the size of the involved heap object by
one word (i.e. length field of FixedArray not needed anymore).
R=mvstanton@chromium.org
Review-Url: https://codereview.chromium.org/2581683003
Cr-Commit-Position: refs/heads/master@{#41752}
