This CL introduces 8 tests that verify that the effects of a grow_memory
instruction executed inside a conditional branch are visible also when
the branch is merged.
The tests verify the output of the current_memory instruction and the
result of loading a variable stored in the grown memory inside the
branch in the following cases:
* the memory is grown inside the if branch (with no else branch);
* the memory is grown inside the if branch (when an else branch exists);
* the memory is grown inside the else branch;
* the memory is grown by different amount of pages inside both the if
and else branches.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I8127ebdf959eed5b7b5ca5aa6033a7ea41465f32
Reviewed-on: https://chromium-review.googlesource.com/617222
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47452}
This reverts commit d04660db3f.
Reason for revert: Suspect for blocking the roll:
https://chromium-review.googlesource.com/c/621191
See:
https://build.chromium.org/p/tryserver.chromium.win/builders/win_optional_gpu_tests_rel/builds/13583
Original change's description:
> [wasm] Move the ModuleEnv to compiler and make it immutable.
>
> This CL (finally) makes the contract between the compiler and the module
> environment clear. In order to compile a function, the caller must provide
> an instance of the compiler::ModuleEnv struct, which contains references
> to code, function and signature tables, memory start, etc.
>
> R=mtrofin@chromium.org,ahaas@chromium.org
>
> Bug:
> Change-Id: I68e44d5da2c5ad44dad402029c2e57f2d5d25b4f
> Reviewed-on: https://chromium-review.googlesource.com/613880
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47418}
TBR=titzer@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: I60a369a43121720fbb13ea6c2ec6ca948d60a20b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/622547
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47451}
This reverts commit 186099d49f.
Reason for revert: Need to revert:
https://chromium-review.googlesource.com/c/613880
Original change's description:
> [wasm] Reference indirect tables as addresses of global handles
>
> This sets us up for getting the wasm code generation off the GC heap.
> We reference tables as global handles, which have a stable address. This
> requires an extra instruction when attempting to make an indirect call,
> per table (i.e. one for the signature table and one for the function
> table).
>
> Bug:
> Change-Id: I83743ba0f1dfdeba9aee5d27232f8823981288f8
> Reviewed-on: https://chromium-review.googlesource.com/612322
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47444}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org
Change-Id: Ic3dff87410a51a2072ddc16cfc83a230526d4c56
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/622568
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47450}
Parse tasks are not currently used, and will need to be changed significantly
for background compilation, so we remove them for now.
BUG=v8:6093,v8:5203
Change-Id: I44559a94ecca85668f0117629d35aaa5f4075745
Reviewed-on: https://chromium-review.googlesource.com/617140
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47446}
This sets us up for getting the wasm code generation off the GC heap.
We reference tables as global handles, which have a stable address. This
requires an extra instruction when attempting to make an indirect call,
per table (i.e. one for the signature table and one for the function
table).
Bug:
Change-Id: I83743ba0f1dfdeba9aee5d27232f8823981288f8
Reviewed-on: https://chromium-review.googlesource.com/612322
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47444}
Before 983eec8979, RewritableExpressions
which had been queued for destructuring assignment rewriting but which
turned out to be part of a binding pattern in arrow function parameters
would be silently ignored by the PatternRewriter. After that CL, they
failed with a DCHECK.
This patch reverts to the previous behavior, with a TODO to handle this
in a better way by dequeuing RewritableExpressions that turned out
to be part of an inner arrow function.
Bug: chromium:756332
Change-Id: I0a9bf51499940c944034d9a8128e89950de38059
Reviewed-on: https://chromium-review.googlesource.com/619506
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47435}
(source_length - 1) can be overflowed, and cause OOB access when source_length
is zero. Thus, just do not operate setting if source_length is zero when
starting TypedArraySetFromOverlapping.
Bug: v8:6704
Change-Id: I5da60590c9a197eae96625a12720f6818b8c598a
Reviewed-on: https://chromium-review.googlesource.com/620452
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47430}
The crash used to happen when trap is a Smi.
Bug: chromium:756608
Change-Id: I0a6f0328afc64d8e521b5b370a291f9aef6b08d0
Reviewed-on: https://chromium-review.googlesource.com/620647
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@google.com>
Cr-Commit-Position: refs/heads/master@{#47429}
This CL (finally) makes the contract between the compiler and the module
environment clear. In order to compile a function, the caller must provide
an instance of the compiler::ModuleEnv struct, which contains references
to code, function and signature tables, memory start, etc.
R=mtrofin@chromium.org,ahaas@chromium.org
Bug:
Change-Id: I68e44d5da2c5ad44dad402029c2e57f2d5d25b4f
Reviewed-on: https://chromium-review.googlesource.com/613880
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47418}
This is a reland of 21da12a983
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=yangguo@chromium.orgTBR=jarin@chromium.org
Bug: v8:6409
Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04
Reviewed-on: https://chromium-review.googlesource.com/618886
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47399}
This CL introduces 6 tests that verify that the effects of a grow_memory
instruction executed inside a function are visible also from the caller of
the function.
The tests verify that:
* the current_memory instruction returns the correct value after
returning from a function that grew memory;
* accessing a memory page that has been created inside a function does
not trap in the caller;
* when a function grows the memory and then store something in the grown
memory, the caller always reads from the grown memory. This checks that
the memory start address gets updated in the caller (the memory buffer
could in fact be relocated by the grow_memory instruction).
These tests are implemented for direct and indirect function calls.
R=ahaas@chromium.org,clemensh@chromium.org
Change-Id: Iac8db0fa7a6dd6f530e090af5423fc165d87e863
Reviewed-on: https://chromium-review.googlesource.com/616150
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47398}
This reverts commit 21da12a983.
Reason for revert: Failing on arm64 simulator
Original change's description:
> [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile
>
> Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
> and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
> function. The code in compiler.cc is refactored to use this function to compile
> the SharedFunctionInfo when compiling a JSFunction.
>
> Also does some other cleanup:
> - Removes CompileUnoptimizedFunction and inlines into new Compiler function
> - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
> out of FinalizeUnoptimizedCompile.
>
> BUG=v8:6409
>
> Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
> Reviewed-on: https://chromium-review.googlesource.com/613760
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47394}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org
Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6409
Reviewed-on: https://chromium-review.googlesource.com/618687
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47397}
The WASM spec maximum memory size is higher than internal V8 maximum object
size. When a memory object grows above this limit (and only in that case), we
should signal an error.
This worked for not-exported memory; however when growing exported memory, the
code was comparing the V8 memory limit with the maximum number of pages defined
in the module, instead of the current number of pages + the number of new
required pages. This lead to signaling errors even when growing exported memory
below the V8 limit if the maximum number of pages specified in the module was
higher than the V8 limit.
GrowMemoryBuffer already checks that we do not grow a memory buffer past the
maximum size specified as parameter, so we can pass it the minimum between the
the V8 limit and the maximum number of pages specified in the module.
This CL introduces a test in test/mjsunit/wasm/import-memory.js that triggers
the problematic path and a patch to fix it.
R=ahaas@chromium.org,clemensh@chromium.org,gdeepti@chromium.org
Change-Id: I5a8da420418b394d61e1ba3cdf4408c3c09e61b6
Reviewed-on: https://chromium-review.googlesource.com/600217
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47395}
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions
and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared)
function. The code in compiler.cc is refactored to use this function to compile
the SharedFunctionInfo when compiling a JSFunction.
Also does some other cleanup:
- Removes CompileUnoptimizedFunction and inlines into new Compiler function
- Moves code to create top level SharedFunctionInfo into CompilerTopLevel and
out of FinalizeUnoptimizedCompile.
BUG=v8:6409
Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3
Reviewed-on: https://chromium-review.googlesource.com/613760
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47394}
Makes ClusterFuzz start fuzzing with the flag on.
BUG=v8:5516
Change-Id: Ia80f7d22f12fe25efb226102a896e8b0e3537947
Reviewed-on: https://chromium-review.googlesource.com/610000
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47366}
Tests were monolithic, with large loops, and slow on ARM64. Refactor to
small tests so they can be sharded better, reduce page size to 1 to
keep the loops small.
BUG=v8:6532
Change-Id: I712551564d4a70fc12acdf114922feb614aeb271
Reviewed-on: https://chromium-review.googlesource.com/611614
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47353}
In the case of a function constructor or eval, we create a new script
object which doesn't have a script name. In this case, we traverse
upwards on the list of SFI's through script->eval_from_shared() to get
the outermost script that was not an eval script and get the script
name from that script.
Bug: chromium:746909, v8:6683, v8:5785
Change-Id: I430459f632a0e3b18fc3111a5cf1c00cedb9f520
Reviewed-on: https://chromium-review.googlesource.com/606701
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47352}
Fixes the implementation of wasm exceptions to use a WasmRuntimeError
object, and set the exception tag value as a property of the
object. This guarantees that an uncaught wasm exception is treated
like all other runtime errors.
Bug: v8:6577
Change-Id: I0ab0130444e745178e86c23b3bc9fc9f385c8d05
Reviewed-on: https://chromium-review.googlesource.com/611124
Reviewed-by: Bill Budge <bbudge@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47346}
It expected its argument to be a JSFunction, but fuzzer tests can
pass anything. Non-JSFunction arguments should just silently be
ignored, just like similar CF-whitelisted runtime functions do.
Bug: chromium:754177
Change-Id: I41b29528bbe72f24b3d84f021b22602160769d26
Reviewed-on: https://chromium-review.googlesource.com/610706
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47316}
When lazy-compiling, it is important we reconstitute the
ModuleEnv accurately. Besides addressing a bug, this change
also does away with the need to relocate memory and globals
parameters (in lazy compilation), by using "the right ones" upfront.
Bug: chromium:753496
Change-Id: I1412a499f05d02d49319fced1b3047698328f3b5
Reviewed-on: https://chromium-review.googlesource.com/609376
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47280}
This is in preparation to the removal of the FullCodeGenerator, we no
longer need the ability to stress the underlying implementation.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254
Reviewed-on: https://chromium-review.googlesource.com/584747
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47276}
This changes the DCHECK (which could correctly fail) to be part of the
conditional that checks if we're in an async function.
Bug: chromium:751789
Change-Id: I3b8c1239ac93190055622c41fa1122e83b69d255
Reviewed-on: https://chromium-review.googlesource.com/607356
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47261}
Because SizeFor only returns aligned values, when we check values
returned there against kMaxSize, they can be larger if they were
rounded up.
It wasn't possible to write a test for the 2-byte version that didn't
regularly OOM.
Bug: chromium:752764
Change-Id: Id2f387449e0fafe633a2fde1ac728be31487f62d
Reviewed-on: https://chromium-review.googlesource.com/607935
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47252}
This fixes a bug affecting module namespace objects, which are currently
implemented using native accessors.
Bug: v8:6681, v8:1569
Change-Id: I6a678652573a332c47315497d927c390d9da0926
Reviewed-on: https://chromium-review.googlesource.com/606027
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47238}
This avoid introduction of {TypeGuard} nodes during load elimination.
Such type guard could lead to contradicting type information where a
constant {NumberConstant} node was guarded to have {ExternalPointer}
type, which would lead to an impossible constraint on representation
selection.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-752826
BUG=chromium:752826
Change-Id: Ida3815af24ccc8a48474b8d66117b9718f61adda
Reviewed-on: https://chromium-review.googlesource.com/605547
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47218}
This code appears to have been wrong forever, as it only
threw in strict mode (presumably predating ES2015 const).
In order to get exactly the right behavior, special
handling of sloppy named function expressions is required.
Rather than polluting PropertyAttributes with another
dummy value, this CL simply adds a bool output argument
to Context::Lookup to indicate that case.
Bug: v8:6677
Change-Id: I34daa5080d291808f10cbaefc91d716f0b22963b
Reviewed-on: https://chromium-review.googlesource.com/602690
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47207}
The ConstructFunctionForwardVarargs and ConstructForwardVarargs
builtins, which are used when inlining the Reflect.construct
builtin into TurboFan optimized code, didn't properly check the
new.target parameter whether it's a constructor.
Bug: chromium:752481
Change-Id: I9b8f8c429d6eaed0ff8d27fc3f6b52eb906766a2
Reviewed-on: https://chromium-review.googlesource.com/604187
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47206}
This reverts commit 15ef03cbf3.
Reason for revert: Found the following bugs
Bug: chromium:752846, chromium:752712, chromium:752850
Original change's description:
> Reland "[builtins] Port getting property from Proxy to CSA"
>
> This reland is after fix in [heap] Delete wrong DCHECK.
> It includes moving ProxyGetProperty to its own stub to reduce
> binary size.
>
> This is a reland of 47a97aa53b
> Original change's description:
> > [builtins] Port getting property from Proxy to CSA
> >
> > Bug: v8:6559, v8:6557
> > Change-Id: If6c51f5483adb73ddd2495cede5d85e887a3c298
> > Reviewed-on: https://chromium-review.googlesource.com/589212
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Commit-Queue: Maya Lekova <mslekova@google.com>
> > Cr-Commit-Position: refs/heads/master@{#47113}
>
> Bug: v8:6559, v8:6557
> Change-Id: I76acd97ba1acb62b7e7983db1741441d997050f0
> Reviewed-on: https://chromium-review.googlesource.com/600215
> Commit-Queue: Maya Lekova <mslekova@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47159}
TBR=jkummerow@chromium.org,mstarzinger@chromium.org,franzih@chromium.org,jgruber@chromium.org,ishell@chromium.org,bmeurer@chromium.org,mslekova@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I51bef25a031b02cf4deab11282473acae57f1ed3
Reviewed-on: https://chromium-review.googlesource.com/603708
Commit-Queue: Maya Lekova <mslekova@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47200}
The interpreter was not able to call imported wasm functions (hitting
UNIMPLEMENTED). This CL fixes this by creating a "CWasmEntry", which is
signature-specific. It has JS linkage and receives the wasm code object
to call and a buffer containing all arguments (similar to the
interpreter entry). It loads all arguments from the buffer and calls the
given code object.
The c-wasm-entry code objects are cached per instance, such that we
only create them once per signature.
These wasm entry stubs will also allow us to call back to compiled code
from the interpreter, which we might want to do to reduce the slowdown
of executing wasm for debugging.
R=titzer@chromium.org
Bug: chromium:735792
Change-Id: I7fecec3a7bec62a9de40fff115b684759b12a28b
Reviewed-on: https://chromium-review.googlesource.com/600308
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47195}
In some cases, PreParser cannot replicate the Scope structure created by
Parser. It happens esp. with arrow function parameters, since the relevant
information is already lost by the time we figure out it's an arrow function.
In these cases, PreParser should bail out of trying to create data for skipping
inner functions.
Implementation notes:
- The arrow function case is more fundamental; the non-arrow case could be
hacked together somehow if we implemented tracking is_simple for each param
separately; but now that it's possible to bail out consistently from both
cases, I don't think the is_simple complication is worth it.
- The added mjsunit test cases are based on the test262 test cases which exposed
the problem.
- cctest/preparser/PreParserScopeAnalysis was exercising similar cases, but the
problem didn't show up because the function parameters didn't contain
skippable functions. Those test cases have been repurposed for testing the
bailout.
- Extra precaution: the bailout tests are in a separate file, to guard from the
bug that a bailout case results in bailing out of *all* data creation, which
would make all skipping tests in the same file useless.
BUG=v8:5516
Change-Id: I4324749a5ec602fa5d7dc27647ade0284a6842fe
Reviewed-on: https://chromium-review.googlesource.com/599849
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47170}
This reland is after fix in [heap] Delete wrong DCHECK.
It includes moving ProxyGetProperty to its own stub to reduce
binary size.
This is a reland of 47a97aa53b
Original change's description:
> [builtins] Port getting property from Proxy to CSA
>
> Bug: v8:6559, v8:6557
> Change-Id: If6c51f5483adb73ddd2495cede5d85e887a3c298
> Reviewed-on: https://chromium-review.googlesource.com/589212
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@google.com>
> Cr-Commit-Position: refs/heads/master@{#47113}
Bug: v8:6559, v8:6557
Change-Id: I76acd97ba1acb62b7e7983db1741441d997050f0
Reviewed-on: https://chromium-review.googlesource.com/600215
Commit-Queue: Maya Lekova <mslekova@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47159}
Calling the Array constructor is an edge case, and we don't seem to
benefit from doing the AllocationSite tracking there as well. In fact
it's a lot of complexity and somewhat blocking the more important
optimization of the subclass constructors.
This is an attempt to nuke the CallIC support for AllocationSites. If
it regresses something important, we'll have to find another way.
Bug: v8:6399
Change-Id: I56f6da29679c516f0a5c3161c2696fc2b8762176
Reviewed-on: https://chromium-review.googlesource.com/600968
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47158}
In order to limit the overall length of error message, limit the output
of string provided by the user. This is implemented by a helper class
which takes the maximum length as template argument and has simple
accessors for the start address and the length of the truncated string.
This is the compromise CL after
https://chromium-review.googlesource.com/c/566815 and
https://chromium-review.googlesource.com/c/594288.
R=titzer@chromium.org
Bug: chromium:740023, chromium:749041, v8:6634
Change-Id: I7c154eb18b3a6befd5ecabbd2f435b015ad71542
Reviewed-on: https://chromium-review.googlesource.com/600547
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47157}
This fixes a missing fast-path check in the code-stub implementation of
the {Array.prototype.filter} method. Appending to the target JSArray is
only correct if the underlying length did not change.
R=jgruber@chromium.org
TEST=mjsunit/regress/regress-6657
BUG=v8:6657
Change-Id: Ida8d3511485b649b70d9a4b161742d494ebe4dac
Reviewed-on: https://chromium-review.googlesource.com/600467
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47156}
Make sure to fail PrepareTransfer when the transferables array contains
a non-ArrayBuffer, otherwise the function leaks a scheduled_exception.
Bug: chromium:736565
Change-Id: I64c2e09eb92720519c7bda2dca41749ff5ac9c8d
Reviewed-on: https://chromium-review.googlesource.com/599357
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47141}
Change-Id: I42f51fd00b1a21a1ff7ef2379fbf81a42266a737
Reviewed-on: https://chromium-review.googlesource.com/599111
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47137}
This is a reland of 470a10015d
Original change's description:
> Start migration of try/throw/catch to match proposal.
>
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
>
> It does the following:
>
> 1) Use exception tags instead of integers.
>
> 2) Only handle empty exception signatures (i.e. no values associated
> with the exception tag.
>
> 3) Only handle one catch clause.
>
> 4) Be sure to rethrow the exception if the exception tag does not match.
>
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
>
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
>
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
>
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}
Bug: v8:6577
Change-Id: I41c3309827c292cb787681a95aaef7cf9b931835
Reviewed-on: https://chromium-review.googlesource.com/598968
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47100}
This behavior has been staged successfully without a bug report, and
has been shipped in the latest versions of Firefox and Safari.
Bug: v8:5070
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I084cae2cc303d6a213bd6789297b91656e162d6b
Reviewed-on: https://chromium-review.googlesource.com/595129
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47098}
This reverts commit 470a10015d.
Reason for revert: GC stress bot failures.
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/14522
Original change's description:
> Start migration of try/throw/catch to match proposal.
>
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
>
> It does the following:
>
> 1) Use exception tags instead of integers.
>
> 2) Only handle empty exception signatures (i.e. no values associated
> with the exception tag.
>
> 3) Only handle one catch clause.
>
> 4) Be sure to rethrow the exception if the exception tag does not match.
>
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
>
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
>
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
>
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}
TBR=bradnelson@chromium.org,eholk@chromium.org,kschimpf@chromium.org
Change-Id: I01dc8c40cc1057333a988c1d275ce5f457b0cb64
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6577
Reviewed-on: https://chromium-review.googlesource.com/598847
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47090}
This CL does the first baby steps on moving the current (experimental)
exception handling to match that of the WebAssembly proposal.
It does the following:
1) Use exception tags instead of integers.
2) Only handle empty exception signatures (i.e. no values associated
with the exception tag.
3) Only handle one catch clause.
4) Be sure to rethrow the exception if the exception tag does not match.
Note: There are many things that need to be fixed, and are too
numerous to list here. However, the code should have TODO's on each
missing parts of the implementation.
Also note that the code currently doesn't handle nested catch blocks,
nor does it change the throw value being an integer. Rather, the
integer value is still being thrown, and currently is the exception
tag. Therefore, we don't build an exception object. This is the reason
why this CL doesn't handle exceptions that pass values.
Also, the current implementation still can't handle multiple modules
because tag resolution (between) modules has not be implemented yet.
Bug: v8:6577
Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
Reviewed-on: https://chromium-review.googlesource.com/591910
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47087}
Consider:
function f() {
return;
}
This CL ensures that the closing brace is considered as covered by
introducing a special case for open-ended range rewrites when the
parent range is the function range itself.
Bug: v8:6000, v8:6661
Change-Id: I0be307759967e9f4df245a4f367326a37dda86fd
Reviewed-on: https://chromium-review.googlesource.com/597651
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47079}
This fixes a corner case of rewriting the transition trees, where the
"interesting symbols" bit was not properly forwarded.
Drive-by-fix: Introduce additional checking in Map::ConnectTransition to
make it easier for clusterfuzz to detect cases we might have missed.
R=mstarzinger@chromium.org
Bug: chromium:751109
Change-Id: I3f1a1e6232db9b3694064b3d4e9f37255b018acc
Reviewed-on: https://chromium-review.googlesource.com/597669
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47075}
This adds support to materialize objects when generating a frame summary
for an optimized frame via {OptimizedFrame::Summarize}. Note that this
means each summary might re-materialize objects and hence produce new
object identities every time. All use sites need to be able to cope with
such semantics.
R=jarin@chromium.org
BUG=v8:6586
Change-Id: I85c66ad3e7d247cd40f37a0a6e4391c0ee279706
Reviewed-on: https://chromium-review.googlesource.com/595745
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47067}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the value is
unwrapped before the builtin call via Await, allowing Promise rejections to
affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when the
generator is resumed with `.return()`, the parameter passed to .return() is
awaited before generator execution properly continues).
BUG=v8:6187, v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.orgTBR=rmcilroy@chromium.org, neis@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id7718028fd555481f9f4ca0dbecfa788e3057c48
Reviewed-on: https://chromium-review.googlesource.com/594500
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#47058}
The test TestExportImportedMemoryGrowMultipleInstances in
test/mjsunit/wasm/import-memory.js had a TODO about not taking into
account the maximum size for exported memory objects, thus permitting to
grow past thhe maximum specified in the exported memory object.
The check is already in place at wasm-objects.cc:266
(https://cs.chromium.org/chromium/src/v8/src/wasm/wasm-objects.cc?rcl=a01b55b548add5aec1d3d4d8fcdadfa01555c6ea&l=266).
This CL removes the TODO and asserts that growing past maximum for
exported objects fails.
R=ahaas@chromium.org, gdeepti@chromium.org
Change-Id: Ifa69e4e85e04bc2280b629cebb30d400cca9420f
Reviewed-on: https://chromium-review.googlesource.com/593948
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Cr-Commit-Position: refs/heads/master@{#47029}
This reverts commit 409f84c93b.
Reason for revert: Breaks nosnap debug:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14288
Original change's description:
> [async-iteration] implement spec-change to `yield` in async generators
>
> Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
>
> AsyncGeneratorResolve no longer unwraps a value component. Instead, the
> value is unwrapped before the builtin call via Await, allowing Promise
> rejections to affect the generator control flow.
>
> Thus, all `yield <expr>` implicitly become `yield await <expr>`.
>
> Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
> the generator is resumed with `.return()`, the parameter passed to .return()
> is awaited before generator execution properly continues).
>
> BUG=v8:5855
> R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
>
> Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
> Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
> Reviewed-on: https://chromium-review.googlesource.com/523844
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47011}
TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,neis@chromium.org,littledan@chromium.org,gsathya@chromium.org,caitp@igalia.com
Change-Id: Ie6ad7e5410a3a89aab7a5dc68de36eb27b9354fe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5855
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/593952
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47013}
Per https://github.com/tc39/proposal-async-iteration/pull/102/files:
AsyncGeneratorResolve no longer unwraps a value component. Instead, the
value is unwrapped before the builtin call via Await, allowing Promise
rejections to affect the generator control flow.
Thus, all `yield <expr>` implicitly become `yield await <expr>`.
Additionally, `return <expr>` becomes `return await <expr>`. Finally, when
the generator is resumed with `.return()`, the parameter passed to .return()
is awaited before generator execution properly continues).
BUG=v8:5855
R=littledan@chromium.org, neis@chromium.org, adamk@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ife084076c3ed434b5467e6aeba14082f8b410ad5
Reviewed-on: https://chromium-review.googlesource.com/523844
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47011}
Remove opt_count from SFI, which only had two real uses:
1. Detecting OSR in tests -- replaced with a stack walk in
%GetOptimizationStatus
2. Naming optimization log files -- replaced with the
optimization id
This allows us to remove a field from the SFI, moving the
bailout reason into the counters field.
As a drive-by, add optimization marker information (e.g.
marked for optimization) to the optimization status.
Change-Id: Id77deb5dd5439dfba058a7e1e1748de26b717d0d
Reviewed-on: https://chromium-review.googlesource.com/592028
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47009}
This reverts commit 072d0e3eb6.
Reason for revert: Performance regressions (https://crbug.com/749041).
Original change's description:
> [wasm] Allow for arbitrarily long error messages
>
> We currently have a fixed limit of 256 characters for error messages
> generated in the decoder. However, we sometimes embed names in it,
> which makes it easy to generate a crash by using long names (e.g. for
> exports) in invalid wasm modules.
> This CL fixes this by switching to a stream based interface, allowing
> to pass arbitrary objects to be printed. With this interface, we can
> easily limit the length of output later.
>
> R=titzer@chromium.org
>
> Bug: chromium:740023
> Change-Id: I2848c31c63a015157e2a3a9458b54e523060cd69
> Reviewed-on: https://chromium-review.googlesource.com/565282
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46860}
TBR=titzer@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:740023, chromium:749041
Change-Id: I005a60d55dcf01d350230f8d98f715bab9c43886
Reviewed-on: https://chromium-review.googlesource.com/593807
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47008}
Print AST needs access to the internalized strings, so make sure AST
is internalized before we print it.
BUG=v8:5203
Change-Id: Ia4995147feb7ec466523a0c4a89620749b23dcab
Reviewed-on: https://chromium-review.googlesource.com/593648
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47006}
Function-granularity coverage skips functions that are both uncovered
and have an uncovered parent. This optimization needs to be tweaked once
block coverage and incremental collection is in play, as it is possible
to have a function with invocation_count == 0 (i.e. uncovered at
function granularity) that still has relevant block-granularity
coverage.
Bug: v8:6000
Change-Id: I4cc81b8a6935aa58e29d383ed4fa749cbfe69352
Reviewed-on: https://chromium-review.googlesource.com/589508
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46991}
With TurboFan, there should no longer be any deopt loops (aside from
bugs). So, the "too many deopts" bailout is no longer needed, at least
in its current form.
This fixes an issue where deopt counts are leaked between native
contexts, resulting in optimization being disabled unnecessarily.
Bug: v8:6402
Change-Id: Ia06374ae6b5c2d473bcdd8eef1284bf02766c2fb
Reviewed-on: https://chromium-review.googlesource.com/588894
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46961}
This includes the catch and finally keywords in the respective range.
For instance:
// Catch range previously: |<--------->|
try { /* ... */ } catch (e) { /* ... */ }
// Now: |<------------------->|
Bug: v8:6000
Change-Id: I1bd9f7fce8bb7de945da83ab512833841b9d956a
Reviewed-on: https://chromium-review.googlesource.com/586598
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46959}
Everything inside a class lives inside the class scope, so
reparenting the class scope is the only operation that
should be done to ClassLiterals during reparenting.
Bug: chromium:740591
Change-Id: Ia5b96b44ff1ca6cfa274effb5a04651809bab9bd
Reviewed-on: https://chromium-review.googlesource.com/588054
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46951}
These counters handle cases in which the catch/finally block contains a jump
statement.
Bug: v8:6000
Change-Id: Ic83f11ee431edabe61f129c9abc3adc12a79c338
Reviewed-on: https://chromium-review.googlesource.com/586595
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46945}
This fixes the second-order Array.prototype function {forEach} and {map}
to now perform a callability check of the given callback function. For
empty arrays it is observable whether such a check outside the loop has
been elided or not.
R=mvstanton@chromium.org
TEST=mjsunit/regress/regress-crbug-747062
BUG=chromium:747062
Change-Id: I1bbe7f44b3b3d18e9b41ad0436975434adf84321
Reviewed-on: https://chromium-review.googlesource.com/588893
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46942}
Note that this also renames the existing "asm_wasm" variant to use the
more appropriate "stress_asm_wasm" name.
R=rmcilroy@chromium.org
BUG=v8:6409
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I1f9550cd03874c678f4583047a4e123a6f090250
Reviewed-on: https://chromium-review.googlesource.com/584879
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46937}
Test mjsunit/optimized-map walked an array through different
ElementsKind transitions, but it failed to verify that the
expected ElementsKind was in place. Although we have a regression
test for the bug, it's a good idea to make sure the basic
test covers all paths.
Bug: chromium:747075
Change-Id: I1424880801857f3356bfd63839d351d6fd1521e0
Reviewed-on: https://chromium-review.googlesource.com/584837
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46933}
Adding (very) small tests for deoptimization.
Some of these tests were failing when the safepoints were not found,
after setting the return address.
BUG=V8:6563
Change-Id: I3af36b193a5982cd73414cc1884c5f0a7a727f5a
Reviewed-on: https://chromium-review.googlesource.com/584751
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#46922}
- No need for multiple assertAsyncRan() calls, just do t.plan(count)
- Previously, if you forget to call assertAsyncRan(), the test will still
pass, which is no longer true.
- No longer hold global state (with
asyncAssertsExpected). Previously if one assert wasn't hit then
there's no way to find out which test failed. You'd have to
comment each test and try again.
- Each test runs independently in the microtask queue.
- Better failure reporting by printing the entire function.
Example error :
=== mjsunit/harmony/promise-prototype-finally ===
abort: Expected asserts: 2, Actual asserts: 1
in test: reject/finally/then
assert => {
assert.plan(2);
Promise.reject(3).finally().then(
assert.unreachable,
x => {
assert.equals(3, x);
});
}
Change-Id: Ic3f6272e1e87b8b0121b8c8c7cce19cf90d1f1be
Reviewed-on: https://chromium-review.googlesource.com/455555
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#46910}
Reland of https://chromium-review.googlesource.com/c/543042/.
Now the OSR phase is only used when OSRing from the ast graph builder.
When OSRing from Turbofan, the implementation is now in the graph
building phase, at the beginning of the VisitBytecode function.
We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes,
nor nodes for the possible code of the OSRed function which is before
the OSRed loops.
The trimming and reducing of the OSR phase is not done either. This
change in the way the way the OSR is done enabled to remove the
workaround to the bug mentioned below.
Bug: v8:6112
Bug: v8:6518
Change-Id: Ia02f2138f54fc79cab2f02fed68d9bb522d6ce14
Reviewed-on: https://chromium-review.googlesource.com/584756
Commit-Queue: Alexandre Talon <alexandret@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46899}
