So far we only recognize the special
NumberFloor(NumberDivide(lhs, rhs))
subgraph when both lhs and rhs are in the Unsigned32 range, and the
result is a PlainNumber. Extend this pattern matching to also cover
NumberFloor(SpeculativeNumberDivide(lhs, rhs))
and to replace the NumberFloor with NumberToInt32 truncation if the
lhs value is in Signed32 range and the rhs is in Unsigned32 range.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2739573004
Cr-Commit-Position: refs/heads/master@{#43642}
The parser already changes all negative equality comparison operations
to their positive pendants in {ParserBase::ParseBinaryExpression}. No
other source of the Token::NE exists in the system. We can remove all
handling from the compiler and interpreter backends.
R=bmeurer@chromium.org
Change-Id: I58722c08dd8e498f20c65886fce86b8172737b10
Reviewed-on: https://chromium-review.googlesource.com/449716
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43627}
We don't need the JSStrictNotEqual operator in the compiler, because
this is never generated by the BytecodeGraphBuilder, and the code in
the AstGraphBuilder was dead code. Also remove the backing builtin
StrictNotEqual.
R=mstarzinger@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2727003006
Cr-Commit-Position: refs/heads/master@{#43594}
Spinning up a new background task is expensive, and many times an existing
task will finish it's work before a new task starts work on a job, so enable
the existing tasks to do more than one background job.
BUG=v8:5203
Change-Id: Ibbef317c8bb3921c36a096fed88d244716be9c42
Reviewed-on: https://chromium-review.googlesource.com/441706
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43593}
We can compile a !== a and Number.isNaN(a) to ObjectIsNaN. The former is
commonly used to check for NaN, i.e. in case of equals in AngularJS.
R=jarin@chromium.org
BUG=v8:5267
Review-Url: https://codereview.chromium.org/2722483003
Cr-Commit-Position: refs/heads/master@{#43572}
This CL fixes unused lambda captures for big endian targets when Clang
is used for build V8.
TEST=
BUG=
Review-Url: https://codereview.chromium.org/2725613002
Cr-Commit-Position: refs/heads/master@{#43511}
Unibrow is currently at Unicode version 7.0.0, which does not
include mongolian vowel separator (\u180E) as white space. In
order to appease test262 at the time however we kept it as a
whitespace.
Test262 has since then been updated. And while this is not an
update of unibrow, we are removing \u180E as white space here.
R=jshin@chromium.org, littledan@chromium.org
BUG=v8:5155
Review-Url: https://codereview.chromium.org/2720953003
Cr-Commit-Position: refs/heads/master@{#43485}
The x64 side is included in https://chromium-review.googlesource.com/c/444226/
BUG=v8:5294
Change-Id: Ie255604c5e38c72e3c2b76e1ca3557a5fde108ee
Reviewed-on: https://chromium-review.googlesource.com/446394
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43481}
This makes it no longer necessary to ensure that V8 and Blink have non-colliding
tags, which makes it easier for them to evolve independently, and also makes
the wire format more suitable for other V8 embedders, who would not
necessarily be surveyed before V8 introduced a new tag that might collide
with theirs.
BUG=chromium:686159
Review-Url: https://codereview.chromium.org/2709023003
Cr-Commit-Position: refs/heads/master@{#43466}
This extends the existing typer for JS-level comparisons to also be
applied on simplified-level number comparisons. Now that nodes having
such operators are introduced early during graph construction, precise
type information has become more important.
R=jarin@chromium.org
TEST=unittests/TyperTest
Change-Id: Ibcfda36cadf72381b3c63138dd8ad2f6b1f7fbba
Reviewed-on: https://chromium-review.googlesource.com/445879
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43447}
Nodes having the {Throw} operator are just used as terminators for
control-flow leaving the function body with an exception completion,
they turn into basic-block terminators within the schedule. Actually
raising an exception is done solely via runtime calls. Hence {Throw}
nodes no longer need any value input.
R=bmeurer@chromium.org
Change-Id: Id6d8e46b12c4b84f4e7a8ac96623c8efb1f27b26
Reviewed-on: https://chromium-review.googlesource.com/446501
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43445}
Marking it as callable makes typeof return 'function' instead of
'object' when invoked on a remote context or object.
BUG=chromium:527190
Review-Url: https://codereview.chromium.org/2715593002
Cr-Commit-Position: refs/heads/master@{#43416}
Enable using BaseWithIndexAndDisplacement addressing mode for an address
used by multiple load/stores. It can reduce one instruction to calculate
the address and one register to store the address.
BUG=
Review-Url: https://codereview.chromium.org/2620293004
Cr-Commit-Position: refs/heads/master@{#43402}
This reverts commit 087e95ba63.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [Compiler] Use IdentityMap to store jobs in CompilerDispatcher.
>
> Stores jobs in an IdentityMap keyed by their SharedFunctionInfo to enable
> fast checking of whether a job is enqueued.
>
> BUG=v8:5203
>
> Change-Id: I6c37972093515a27077f79594cad27e32e1a4e7c
> Reviewed-on: https://chromium-review.googlesource.com/444768
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#43370}
TBR=rmcilroy@chromium.org,jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5203
Change-Id: I5d1101bdae6939378dad595b26698fe2aaaad35e
Reviewed-on: https://chromium-review.googlesource.com/446357
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43372}
Stores jobs in an IdentityMap keyed by their SharedFunctionInfo to enable
fast checking of whether a job is enqueued.
BUG=v8:5203
Change-Id: I6c37972093515a27077f79594cad27e32e1a4e7c
Reviewed-on: https://chromium-review.googlesource.com/444768
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43370}
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}
