Validation normally happens while generating the turbofan graph of a
wasm function. For lazy compilation (behind the flag
--wasm-lazy-compilation), we skip this graph generation step during
module generation. Thus we need to validate explicitely.
R=ahaas@chromium.org
BUG=chromium:724851
Change-Id: Ic70887c0d823460a272d0bb636dc98b2b7a7e55e
Reviewed-on: https://chromium-review.googlesource.com/509574
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45478}
If the maximum number of memory pages is raised using
--wasm-max-mem-pages, we might allocate more than kMaxInt bytes for
wasm memory. The byte length is stored as int in JSArrayBuffer, hence
this can lead to failures.
Thus, we now additially check against kMaxInt, and fail instantiation
if this check fails.
Drive-by: Add/fix more bounds checks.
R=ahaas@chromium.org
BUG=chromium:724846
Change-Id: Id8e1a1e13e15f4aa355ab9414b4b950510e5e88a
Reviewed-on: https://chromium-review.googlesource.com/509255
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45465}
This makes sure that function imports without a single call site within
the asm.js module are still preserved in the WebAssembly module, hence
preserving intended JavaScript semantics during module instantiation.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-722348
BUG=chromium:722348
Change-Id: I624d0e52b32b864c1e3002187a99a0a63834a4b0
Reviewed-on: https://chromium-review.googlesource.com/509450
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45452}
This fixes crashes during validation when trying to construct modules
with excessively large function tables. The {WasmModuleBuilder} now
gracefully checks against existing WebAssembly implementation limits.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-715455
BUG=chromium:715455
Change-Id: Ia9738cb0b49a1eb4caf073b75301c0303f295699
Reviewed-on: https://chromium-review.googlesource.com/509530
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45429}
Generators were previously treated as "top level" for preparsing purposes,
since all their variables are context-allocated. But doing so isn't quite
correct: the allocation of the "arguments" variable for a generator
depends on whether it's referenced, and so an inner arrow function
which references "arguments" won't properly trigger allocation of
"arguments" since the reference will not be noticed in the preparser.
The same problem exists for "this" since commit 68f0a47b28a96a4966e7b747bfa304b555e726d1;
before that commit, all generators implicitly referenced their "this" argument
as part of the desugaring. With that implicit reference gone, "this"
falls into the same problem as arguments.
This patch restricts the special "top level" treatment to modules,
which have only a trivial "this" binding (it's always undefined), and no
arguments binding. Moreover, all code inside modules is strict, meaning
that unresolved references to "this" will also result in undefined.
R=marja@chromium.org
Bug: chromium:723132
Change-Id: I814d145fb8f3f1a65abb48e4e35595428d063051
Reviewed-on: https://chromium-review.googlesource.com/508055
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45399}
IC system does its best to properly mark stable transition source maps
as unstable (see https://chromium-review.googlesource.com/483442)
however an already recorded map can be deprecated later and the
optimizing compiler may try to generate an elements kind transition
from the updated version of deprecated map which can "become" stable
again.
Bug: chromium:723455
Change-Id: Ic0c392f153587c3cd7c7623a3a6ea85ec72ad5bd
Reviewed-on: https://chromium-review.googlesource.com/507887
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45384}
Original CL description:
[compiler] Delay allocation of heap numbers for deoptimization literals.
... until after the main bulk of code generation, which will soon run on a
different thread.
Bug: v8:6048, chromium:722978
Change-Id: I690c0b009211a2bac60cf06f577720a914c21000
Reviewed-on: https://chromium-review.googlesource.com/507207
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45371}
The underlying issue is that TF Nodes cannot handle input counts
outside the integer range. On an illegal br_table instruction, we
generated a switch node with a control output count >kMaxInt.
Operator::ControlOutputCount turned this into a negative integer later,
leading to a failing DCHECK.
Since such large numbers cannot occur in any valid wasm function anyway,
we just add an additional check to the br table count. There is already
a TODO in the code to change Operator::ControlOutputCount to size_t.
R=ahaas@chromium.org
BUG=chromium:722445
Change-Id: I1975072226e073dee6c8da3b9fa9a050a4695917
Reviewed-on: https://chromium-review.googlesource.com/505496
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45365}
The interpreter does not implement all asm.js specific opcodes. Thus
the combination of --validate-asm and --wasm-interpret-all might crash.
The interpreter does not need to execute asm.js modules, as they are
debugged by executing them in turbofan instead of the wasm interpreter.
This CL thus excludes asm.js modules from --wasm-interpret-all.
R=ahaas@chromium.org
BUG=chromium:719175
Change-Id: I14228ea11ee3ea8a229cfa6e4179338a442b6cca
Reviewed-on: https://chromium-review.googlesource.com/506160
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45364}
Now that the optimized code hangs off the feedback vector, it is possible
to check whether a function has optimized code available every time it's
called in the interpreter entry trampoline. If optimized code exists, the
interpreter entry trampoline 'self-heals' the closure to point to the
optimized code and links the closure into the optimized code list.
BUG=v8:6246
Change-Id: I53b095db2a75ae4824c8195faf8649d766c86118
Reviewed-on: https://chromium-review.googlesource.com/501967
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45328}
This makes sure that the evaluation result of the first expression in
for-statements is properly dropped, to leave the stack in a balanced
state after the statement. It also makes sure validation failures in
said expression are handled correctly.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-721835
BUG=chromium:721835
Change-Id: I7e6cff4cea0bbf5aad6a3459e27a08ea814dbdbe
Reviewed-on: https://chromium-review.googlesource.com/506148
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45299}
With this CL SloppyArguments immediately go to dictionary elements on
deletion, keeping the arguments backing store packed.
Bug: v8:6251
Change-Id: I90d1972179447bf6810e7fe2b8e0bc8703b38d9d
Reviewed-on: https://chromium-review.googlesource.com/486921
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45286}
Clearing the pending exception is not enough - if we want to swallow an
exception while currently on top of an external handler (e.g. TryCatch),
we also need to clear external_caught_exception.
BUG=chromium:719380
Review-Url: https://codereview.chromium.org/2870423002
Cr-Commit-Position: refs/heads/master@{#45247}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246,chromium:718891
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: I3bb9ec0cfff32e667cca0e1403f964f33a6958a6
Reviewed-on: https://chromium-review.googlesource.com/500134
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45234}
Due to speculative optimizations, the compiler can run into situations
where it's asked perform impossible operations, like loading a tagged
element as a float64 instead. All of this is guaranteed to be in dead
code (unless there's a bug), but leads to confusion and violates
assumptions in the compiler (that make perfect sense for code that is
not dead). So teach LoadElimination not to mix up element accesses with
incompatible representations.
BUG=chromium:719479
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2866233002
Cr-Commit-Position: refs/heads/master@{#45185}
This reverts commit 662aa425ba.
Reason for revert: Crashing on Canary
BUG=chromium:718891
Original change's description:
> Reland: [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
> TBR=yangguo@chromium.org,ulan@chromium.org
>
> Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
> Reviewed-on: https://chromium-review.googlesource.com/494487
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45084}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=v8:6246
Change-Id: Idab648d6fe260862c2a0e35366df19dcecf13a82
Reviewed-on: https://chromium-review.googlesource.com/498633
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45174}
After the recent fast-property deletion changes, there can be a
non-empty out-of-object backing store (that previously held properties)
even though the next double property will be stored in-object.
BUG=chromium:718779
Review-Url: https://codereview.chromium.org/2861093004
Cr-Commit-Position: refs/heads/master@{#45146}
Different Intl features (DateTimeFormat, NumberFormat, etc) have
different lists of locales supported. Previously, the default locale
was set to "und", as opposed to what was detected from the surrounding
system, if any of these features was missing data. With this patch,
only that feature is set to "und". In this way, the data quality should
be just as good as if there were no fallback logic, but at the same time,
resolvedOptions().locale should show the locale actually in effect.
R=adamk,jshin
BUG=v8:6288
Change-Id: I62b083a1dde2465cb1541cb18ecc7e59f9097bc0
Reviewed-on: https://chromium-review.googlesource.com/492886
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45109}
If an ArrayBuffer is setup through the WebAssembly.Memory constructor, identify these with a flag and avoid optimizations in js-typed-lowering.cc. This is needed becasue buffers associated with memory objects can be grown/detached leading to crashes.
BUG=chromium:717194
Review-Url: https://codereview.chromium.org/2862763002
Cr-Commit-Position: refs/heads/master@{#45105}
Storing a data property on |target| can change |source|'s map
if |target| and |source| are the same object.
BUG=chromium:716520
Review-Url: https://codereview.chromium.org/2855133006
Cr-Commit-Position: refs/heads/master@{#45097}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
TBR=yangguo@chromium.org,ulan@chromium.org
Change-Id: Ic83e4011148164ef080c63215a0c77f1dfb7f327
Reviewed-on: https://chromium-review.googlesource.com/494487
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45084}
When deleting the most recently added fast property from an object
by undoing its last map transition, we must clear any recorded slots.
This can only be done in C++, so this functionality must move out
of the stub.
Also update a CHECK in the JSObject verifier to allow backing stores
sticking around after such property deletions.
BUG=chromium:716912,chromium:714981
Review-Url: https://codereview.chromium.org/2854373002
Cr-Commit-Position: refs/heads/master@{#45069}
More care must be taken to remain on the fast path in the face of
@@species constructors.
BUG=chromium:716044
Review-Url: https://codereview.chromium.org/2846963003
Cr-Commit-Position: refs/heads/master@{#45065}
The --wasm-interpret-all flag is mainly used for debugging. Combining it
with lazy compilation is unreasonable and would create a lot of special
cases in both code paths. Hence this CL disallows the combination of
these two flags by adding a negative flag implication.
R=rossberg@chromium.org
BUG=chromium:715216
Change-Id: I777e21d7e64f567e2728498dbb6f5b0709cd28f1
Reviewed-on: https://chromium-review.googlesource.com/494486
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45047}
ErrorThrower::Reify() should only be called if an error is actually set.
This CL introduces a Reset() method to replace the obsolete (now
disallowed) usages.
R=mtrofin@chromium.org
BUG=chromium:717056
Change-Id: I41b989a9c7b33591ee26ec6d43540a38289ab54f
Reviewed-on: https://chromium-review.googlesource.com/493506
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45039}
This reverts commit c5ad9c6d8e.
Reason for revert: Fails on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/12661
Original change's description:
> [TypeFeedbackVector] Store optimized code in the vector
>
> Since the feedback vector is itself a native context structure, why
> not store optimized code for a function in there rather than in
> a map from native context to code? This allows us to get rid of
> the optimized code map in the SharedFunctionInfo, saving a pointer,
> and making lookup of any optimized code quicker.
>
> Original patch by Michael Stanton <mvstanton@chromium.org>
>
> BUG=v8:6246
>
> Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
> Reviewed-on: https://chromium-review.googlesource.com/476891
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45022}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,mvstanton@chromium.org,jarin@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6246
Change-Id: I9cd5735b03898cae6ae7adea0f19d32fceb31619
Reviewed-on: https://chromium-review.googlesource.com/493287
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45027}
Since the feedback vector is itself a native context structure, why
not store optimized code for a function in there rather than in
a map from native context to code? This allows us to get rid of
the optimized code map in the SharedFunctionInfo, saving a pointer,
and making lookup of any optimized code quicker.
Original patch by Michael Stanton <mvstanton@chromium.org>
BUG=v8:6246
Change-Id: I60ff8c408c3001bc272b4b198c9cbaea2872a9e5
Reviewed-on: https://chromium-review.googlesource.com/476891
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45022}
As required by #sec-built-in-function-objects.
They were strict functions before (see
e2f1c26982), but that got lost when they
were ported to ASM builtins.
This makes optimized and non-optimized code agree on the same behavior
in regress-105.js.
BUG=v8:105,v8:5778,v8:6325
Review-Url: https://codereview.chromium.org/2848313004
Cr-Commit-Position: refs/heads/master@{#45012}
This CL changes certain frequently-called Array builtins to use CodeStubArguments
rather than peek at the stack frames above array builtins to determine if options
arguments have been passed into them.
Previous failure likely due to unfortunate/unluckily timed GC that moved due to
changed timing/allocation from this CL. Test mitigation for allocation-site-info.js
included.
BUG=v8:1956
LOG=N
Review-Url: https://codereview.chromium.org/2829093004
Cr-Commit-Position: refs/heads/master@{#44998}
Reason for revert:
Still fails. Likely has to do with gc heap size for allocation site tests, mitigation pending...
Original issue's description:
> [turbofan] Reland: Avoid going through ArgumentsAdaptorTrampoline for select CSA array builtins
>
> This CL changes certain frequently-called Array builtins to use CodeStubArguments
> rather than peek at the stack frames above array builtins to determine if options
> arguments have been passed into them.
>
> Previous failure cannot be reproed with failing config. Flake?
>
> BUG=v8:1956
> LOG=N
>
> Review-Url: https://codereview.chromium.org/2829093004
> Cr-Commit-Position: refs/heads/master@{#44996}
> Committed: 7ca381e847TBR=mvstanton@chromium.org,ishell@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1956
Review-Url: https://codereview.chromium.org/2851063002
Cr-Commit-Position: refs/heads/master@{#44997}
This CL changes certain frequently-called Array builtins to use CodeStubArguments
rather than peek at the stack frames above array builtins to determine if options
arguments have been passed into them.
Previous failure cannot be reproed with failing config. Flake?
BUG=v8:1956
LOG=N
Review-Url: https://codereview.chromium.org/2829093004
Cr-Commit-Position: refs/heads/master@{#44996}
Reason for revert:
Nosnap failure
Original issue's description:
> [turbofan] Avoid going through ArgumentsAdaptorTrampoline for select CSA/C++ builtins
>
> This CL changes certain frequently-called Array builtins to use CodeStubArguments
> rather than peek at the stack frames above array builtins to determine if options
> arguments have been passed into them.
>
> BUG=v8:1956
> LOG=N
>
> Review-Url: https://codereview.chromium.org/2829093004
> Cr-Commit-Position: refs/heads/master@{#44994}
> Committed: 680356278dTBR=mvstanton@chromium.org,ishell@chromium.org,bmeurer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:1956
Review-Url: https://codereview.chromium.org/2851703005
Cr-Commit-Position: refs/heads/master@{#44995}
This CL changes certain frequently-called Array builtins to use CodeStubArguments
rather than peek at the stack frames above array builtins to determine if options
arguments have been passed into them.
BUG=v8:1956
LOG=N
Review-Url: https://codereview.chromium.org/2829093004
Cr-Commit-Position: refs/heads/master@{#44994}
1. Replaces --crankshaft with --opt in tests.
2. Also fixes presubmit to check for --opt flag when
assertOptimized is used.
3. Updates testrunner/local/variants.py and
v8_foozie.py to use --opt flag.
This would mean, nooptimize variant means there are
no optimizations. Not even with %OptimizeFunctionOnNextCall.
Bug:v8:6325
Change-Id: I638e743d0773a6729c6b9749e2ca1e2537f12ce6
Reviewed-on: https://chromium-review.googlesource.com/490206
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44985}
Clearing out the constructor field is invalid in the case where the
function's map has transitioned since the last SetPrototype call.
Bug: chromium:714972
Change-Id: Ie918702a128219c4995b805f7c9a53b41cc4e4b6
Reviewed-on: https://chromium-review.googlesource.com/486130
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44906}
This fixes the bounds checking of "unsigned" numeric literals (those
that do not contains dots) by the parser. In particular this fixes a
bogus truncation to 32-bit in the scanner. It also makes the scanner
more robust by limiting the range of those numeric literals, hence
completely avoiding rounding loss or truncation errors.
R=clemensh@chromium.org
TEST=unittests/AsmJsScannerTest.UnsignedNumbers
BUG=v8:6298
Change-Id: Id31ab3c652e99fa8d3d6663315768e1bfaf3b773
Reviewed-on: https://chromium-review.googlesource.com/486881
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44890}
Only create a singleton array for Array(len) if Type(len) cannot be
Number, otherwise we might need to throw an exception instead.
BUG=chromium:715404
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2838123004
Cr-Commit-Position: refs/heads/master@{#44886}
With this CL SloppyArguments immediately go to dictionary elements on
deletion, keeping the arguments backing store packed.
Bug: v8:6251
Change-Id: I2afa4fb5f0af9942eee0a1606942f5f289539330
Reviewed-on: https://chromium-review.googlesource.com/480379
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44857}
This fixes propagation of validation failures that happen during the
validation of a heap access expression in {ValidateHeapAccess}.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-714971
BUG=chromium:714971
Change-Id: I8f91ac1da34ae50fdde2938f61b6468cdac92b6e
Reviewed-on: https://chromium-review.googlesource.com/486801
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44851}
In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.
This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.
TBR=bmeurer@chromium.org (just adding a comment)
Previously reviewed at https://codereview.chromium.org/2830093002
Previously landed as 98acfb36e1 / r44799
Review-Url: https://codereview.chromium.org/2840583002
Cr-Commit-Position: refs/heads/master@{#44808}
This makes sure that typed array constructors (e.g. Int8Array, ...) used
within an asm.js module are considered uses of stdlib values, and hence
are checked during module instantiation.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6280
BUG=v8:6280,chromium:714537
Change-Id: Ic5d689f5319c4dac4e9df3dca4a8cf5a4edd890b
Reviewed-on: https://chromium-review.googlesource.com/485521
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44800}
In general, deleting a property from a fast-properties object
requires transitioning the object to dictionary mode. However,
when the most-recently-added property is deleted, we can simply
roll back the last map transition that the object went through.
This is a performance experiment: it should make things faster,
but if it turns out to have more negative than positive impact,
we will have to revert it.
TBR=bmeurer@chromium.org (just adding a comment)
Review-Url: https://codereview.chromium.org/2830093002
Cr-Commit-Position: refs/heads/master@{#44799}
Ensure source map is not stable if elements kind transitions are expected.
BUG=chromium:700733
Change-Id: Ie937e7064127250b1100109986c3e9b411fae1d6
Reviewed-on: https://chromium-review.googlesource.com/483442
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44780}
The included test case illustrates the problem. It subtracts (16 << 27)
from another number. The Machine Operator Reducer would replace the
shift computation with 0x0000000080000000, and then change the subtract
to an add of -(0x0000000080000000), which is 0xffffffff80000000.
The instruction selector would determine that this value could be an
immediate, because it fits in 32 bits, so it would select the lea
instruction. Finally, the code generator would detect that the
immediate was less than 0, flip the sign and replace the add with a
subtract of 0x80000000. Because the x64 subtract instruction's
immediate field is 32 bits, the processor would interpret this as
0xffffffff80000000 instead of an unsigned value.
This change fixes the issue by making the CanBeImmediate check
explicitly compare against INT_MIN and INT_MAX. We disallow INT_MIN
as an immediate precisely because we cannot tell 0x0000000080000000
from 0xffffffff80000000 when truncated to 32 bits.
Bug: chromium:711203
Change-Id: Ie371b8ea290684a6bb723bae9c693a866f961850
Reviewed-on: https://chromium-review.googlesource.com/482448
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44758}
The typing rule for JSCreateArguments must properly declare rest
parameters as arrays and only consider sloppy and strict arguments
objects as Type::OtherObject.
TBR=jarin@chromium.org
BUG=v8:6262,chromium:712802
Review-Url: https://codereview.chromium.org/2828573004
Cr-Commit-Position: refs/heads/master@{#44712}
When --harmony-strict-legacy-accessor-builtins is enabled, it brings
V8's behavior in line with the spec and more recent versions of
SpiderMonkey and JSC:
- No implicit receiver coercion
- Attempting to redefine a non-configurable property throws
Bug: v8:5070
Change-Id: I82b927538604136c0c550e19bcc606fbfea1377e
Reviewed-on: https://chromium-review.googlesource.com/478312
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44703}
+ additional fixes uncovered by bug, and addressed remaining feedback
from original CL (https://codereview.chromium.org/2806073002/).
Note that the regression test differs slightly from the bug reported one,
in that it catches the RangeError which will eventually be thrown due
to call stack size being exceeded.
BUG=chromium:712569
Review-Url: https://codereview.chromium.org/2825073002
Cr-Commit-Position: refs/heads/master@{#44700}
This fixes the de-duplication logic used when writing the deoptimizer
translation of a frame-state containing {kArgumentsElementsState}. The
object counts as a captured object and participates in the numbering of
duplicated objects.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-711166
BUG=chromium:711166
Change-Id: I4a3b892017ab8217197e5f94c1a0975d0cd6979f
Reviewed-on: https://chromium-review.googlesource.com/476631
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44692}
Currently when the module has memory specified in the compiled bytes, but with no initial memory
exported memory assigns a bogus buffer to the instance. When grow_memory is called on this buffer, it tries to patch an incorrect address.
- Fix exported memory to handle no initial memory
- Fix grow_memory to handle uninitialized buffers
BUG=chromium:710844
R=bradnelson@chromium.org
Review-Url: https://codereview.chromium.org/2820223002
Cr-Commit-Position: refs/heads/master@{#44671}
If the current context is overwritten by doing Realm.navigate(0) we
fail to delete the module embedder data from the correct current
context, because we have an handle to the old context which was
already cleaned up by calling DisposeRealm in RealmNavigate.
This patch disallows navigation to the first realm.
Bug: chromium:711165
Change-Id: I6b9d3187367dae9d1fe38c0efa361d461c94c917
Reviewed-on: https://chromium-review.googlesource.com/476970
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44656}
This fixes the existing lowering of {JSGetSuperConstructor} nodes to
unconditional throws. The above operator is marked as {kNoWrite} but
runtime calls are not marked as such. Any deoptimizing operation after
the throw would not be able to find a valid {Checkpoint}. We remove the
lowering case in question.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-6248
BUG=v8:6248
Change-Id: I22c922947336254502f698b02f944cf35dd8688a
Reviewed-on: https://chromium-review.googlesource.com/476570
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44632}
The hole NaN should also have proper Type::Hole, and not silently hide
in the Type::Number. This way we can remove all the special casing for
the hole NaN, and we also finally get the CheckNumber right.
This also allows us to remove some ducktape from the Deoptimizer, as for
escape analyzed FixedDoubleArrays we always pass the hole value now to
represent the actual holes.
Also-By: jarin@chromium.org
BUG=chromium:684208,chromium:709753,v8:5267
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2814013003
Cr-Commit-Position: refs/heads/master@{#44603}
RationalizeConsecutiveAtoms optimizes ab|ac|az to a(?:b|c|d).
Ensure that this optimization does not split surrogate pairs in unicode
mode.
BUG=chromium:641091
Review-Url: https://codereview.chromium.org/2813893002
Cr-Commit-Position: refs/heads/master@{#44599}
As of crrev.com/2760213003, the CheckBounds operator passes a truncation
that identfies zero and minus zero. However that was not reflected in
the typing rule, and as such the type of CheckBounds(-0,length) was
always Type::None. That confused the typed alias analysis in the
LoadElimination and led to ignoring StoreElement nodes.
BUG=chromium:708050
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2812013006
Cr-Commit-Position: refs/heads/master@{#44598}
This fixes {JSCreateLowering} to traverse boilerplate objects in the
same order the runtime uses (i.e. properties first, elements second).
That order is hard-coded in the nesting of {AllocationSite} objects.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-crbug-709537
BUG=chromium:709537
Change-Id: I8f446a0880448ea88a3e242e92d11d611581a42b
Reviewed-on: https://chromium-review.googlesource.com/474028
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44563}
We assumed that every JSArray would have a JSObject as a prototype,
but it could be null, in which case we bail out to slow path.
Also rename spread_array variable here, because this fast-path
isn't just used by spreads anymore.
Bug: chromium:707675
Change-Id: I8045d83977735dd00c3ebde2e0704f6b04afdedd
Reviewed-on: https://chromium-review.googlesource.com/472907
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44531}
Loading the map, performing a side-effect, and then using the stored
pointer for the fast-path check is another antipattern that can lead to
unintended shapes on the fast path.
BUG=chromium:709029
Review-Url: https://codereview.chromium.org/2807153002
Cr-Commit-Position: refs/heads/master@{#44528}
Ensuring we move forward all the deferred handles, in all cases.
BUG=
Review-Url: https://codereview.chromium.org/2807013002
Cr-Commit-Position: refs/heads/master@{#44525}
We went on decoding the next section, which happened to be the start
section. But since the function section had an error, the signature
pointer was not still {nullptr} on the start function, leading to a
segfault.
Drive-by fix: Improve decoder trace output.
R=ahaas@chromium.org
BUG=chromium:708714, chromium:708787
Change-Id: I5ae2adb32764b9d154f1ca878019f26ac31839b4
Reviewed-on: https://chromium-review.googlesource.com/472847
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44521}
The DCHECK added by https://chromium-review.googlesource.com/461827 was not true
in case we failed to compile the function.
BUG=chromium:708598
Change-Id: I6a542c3ac6281c0549396b4ff0af34ea44450006
Reviewed-on: https://chromium-review.googlesource.com/472826
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44513}
The format of the name section changed recently. It now contains
subsections of different type (currently for function names or local
variable names).
This CL changes our internal wasm module builders (in JS and C++) to
emit this new format, and changes the decoder to understand it.
We currently only parse the function name section, and ignore names of
local variables. I will later extend this to parse local variable names
when needed for debugging.
R=ahaas@chromium.org, rossberg@chromium.org
BUG=v8:6222
Change-Id: I2627160c25c9209a3f09abe0b88941ec48b24434
Reviewed-on: https://chromium-review.googlesource.com/470247
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44492}
This fixes behavior for HeapNumber {index} arguments passed to
AdvanceStringIndex.
Previously, we'd blindly treat {index} as a Smi. Passing a HeapNumber instead
would result in a Smi addition on the tagged HeapNumber pointer.
BUG=chromium:709015
Review-Url: https://codereview.chromium.org/2798933003
Cr-Commit-Position: refs/heads/master@{#44458}
This CL fixes two more cases in which a regexp could unintentionally transition
to slow mode while on the fast path, leading to possible OOB accesses of
lastIndex.
In both cases, the fix is to re-check the shape and possibly bail to runtime.
BUG=chromium:708247,v8:6210
Review-Url: https://codereview.chromium.org/2803603005
Cr-Commit-Position: refs/heads/master@{#44451}
This fixes a corner case which allowed warnings during the asm.js
instantiation to be promoted to actual exceptions. Even instantiation
attempts that fail are not allowed to throw exceptions observable by
JavaScript, but need to fall back to JavaScript execution.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6203
BUG=v8:6203
Change-Id: I86f5a3adda4bcfe63b5cddc42d8ae1c3dbb88147
Reviewed-on: https://chromium-review.googlesource.com/468808
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44414}
Remove destructuring assignments (parsed during arrow function formal
parameters) from queue for rewriting if parsing a lazy top-level arrow function.
Built ontop of https://chromium-review.googlesource.com/c/464769/
BUG=chromium:706234, chromium:706761, v8:6182
R=marja@chromium.org, adamk@chromium.org, vogelheim@chromium.org
Change-Id: Ib35196b907350d1d78e4c3fcbf4cc971bf200948
Reviewed-on: https://chromium-review.googlesource.com/465415
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44393}
This makes temporary variables nestable and fixes borked nesting with
function table calls by introducing a {TemporaryVariableScope} helper.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6196
BUG=v8:6196
Change-Id: Ie760f27ce9ede3d4d5dacdebdc295c56cc666970
Reviewed-on: https://chromium-review.googlesource.com/467327
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44367}
Currently x instanceof RegExp checks cannot take the fast path, since
the RegExp constructor has dictionary properties. To avoid that, just
forcibly migrate the RegExp constructor to fast properties again once
it's fully setup in the bootstrapper. This yields a 10x improvement for
x instanceof RegExp checks.
R=yangguo@chromium.org
BUG=v8:5902
Review-Url: https://codereview.chromium.org/2786143004
Cr-Commit-Position: refs/heads/master@{#44316}
Fixes a crash found by clusterfuzz caused by a call to
std::vector::reserve with a huge capacity, and reverts to ZoneList
handling as a tentative fix for performance regressions on the slow
@@replace path.
BUG=chromium:707187,chromium:706748,v8:5437
Review-Url: https://codereview.chromium.org/2787343002
Cr-Commit-Position: refs/heads/master@{#44311}
The last CL https://chromium-review.googlesource.com/c/456707/ caused
some pretty heavy performance regressions. After experimenting, it
seems the easiest and most straight-forward way to copy the elements
into the new typed array is to do it in JS.
Adds a fast path for typed arrays, where the source typed array has
the same elements kind, in which case we can just copy the backing
store using memcpy.
This CL also removes regression test 319120 which is from a pwn2own
vulnerability. The old code path enforced a maximum byte_length
that was too low, which this change removes. The length property of
the typed array must be a Smi, but the byte_length, which can be up
to 8x larger than length for a Float64Array, can be a heap number.
We can also re-use some of the logic from ConstructByLength when
deciding whether to allocate the buffer on- or off-heap, so that
is factored out into InitializeBasedOnLength. We can also re-use
the DoInitialize helper instead of calling into the runtime,
meaning we can remove InitializeFromArrayLike.
BUG=v8:5977,chromium:705503,chromium:705394
Change-Id: I63372652091d4bdf3a9491acef9b4e3ac793a755
Reviewed-on: https://chromium-review.googlesource.com/459621
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44301}
The test was out-dated. The wasm bytes still had the version 0xd, and
no END instruction at the end of the function. In addition, the test
used asynchronous compilation but did not wait for the promise to
resolve.
R=clemensh@chromium.org
Change-Id: Ib01f47ac8f668401ed14470af7100e990e5bbd94
Reviewed-on: https://chromium-review.googlesource.com/463286
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44276}
The inlining logic doesn't account for the fact that the derived
constructor could return a primitive, thus leaking the implicit
receiver (which is the hole).
R=jarin@chromium.org
BUG=chromium:706642
Review-Url: https://codereview.chromium.org/2788603002
Cr-Commit-Position: refs/heads/master@{#44264}
The int64-lowering lowers return nodes which return one int64 value into
a return node which returns two int32 values. For this lowering it has
to adjust the input count of the return operator.
The existing code assumed that if the signature of a function said that
the return type is int64, then all return nodes have int64 inputs.
However, with a recent CL we also introduced void returns. With this CL
I check if the number of inputs of a return node changes with the
DefaultLowering, and only if the number of inputs changes, then I check
if I also have to change the operator of the return node.
R=mstarzinger@chromium.org
TEST=mjsunit/regress/wasm/regression-6164
BUG=v8:6164
Change-Id: I004ab1b4be942cc045719f306705d95b48707a1c
Reviewed-on: https://chromium-review.googlesource.com/461941
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44232}
Compilation can fail e.g. on stack overflow. This ensures that we exit
early from StringReplaceGlobalRegExpWithString in that case.
BUG=v8:5437,chromium:705934
Review-Url: https://codereview.chromium.org/2778953004
Cr-Commit-Position: refs/heads/master@{#44215}
As far as I can see, we have had this bug as long as destructuring assignments
have been there (i.e., this is not regression).
The problem was that Parser::DoParseFunction parsed the arrow function parameters
but didn't rewrite the destructuring assignments in them.
BUG=chromium:704811
Change-Id: I0b1424e7d5103eda6efd51b403fe81a4ee235e01
Reviewed-on: https://chromium-review.googlesource.com/459618
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44177}
This reverts commit 6ad5ca59c9.
Reason for revert: Breaks on noi18n bot, needs fix in the new regression test
Original change's description:
> [wasm] Check the result of Promise::Resolver
>
> We check that if we do not get a result, or if we get a negative result,
> then there has to be a scheduled exception.
>
> R=clemensh@chromium.org
> TEST=mjsunit/regress/wasm/regression-704127
> BUG=chromium:704127
>
> Change-Id: I3fef3cc02f685a9cbc3f10203e2a59b61b3702d5
> Reviewed-on: https://chromium-review.googlesource.com/458282
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44144}
TBR=ahaas@chromium.org,clemensh@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:704127
Change-Id: Ibf6d27929c88064bc2755688358998640092e31a
Reviewed-on: https://chromium-review.googlesource.com/459512
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44145}
We check that if we do not get a result, or if we get a negative result,
then there has to be a scheduled exception.
R=clemensh@chromium.org
TEST=mjsunit/regress/wasm/regression-704127
BUG=chromium:704127
Change-Id: I3fef3cc02f685a9cbc3f10203e2a59b61b3702d5
Reviewed-on: https://chromium-review.googlesource.com/458282
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44144}
Since we no longer support the ignition-staging configuration
any longer, we can retire the three tier pipeline and the
CompileBaseline functionallity.
We still need support for JSFunction self healing due to
liveedit (which for --no-turbo might end up replacing a
forced Ignition function with a FCG function) - we can
remove this once we remove --no-turbo support.
BUG=v8:4280
Change-Id: I5482abd17785324654e022affd6bdb555b19b181
Reviewed-on: https://chromium-review.googlesource.com/452620
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44141}
