For unknown Argument object Maps we have to expect that constants fields
are kept on the Map.
Bug: chromium:729597
Change-Id: I110f77455ce434a431c8de27d021b1a5deb86f30
Reviewed-on: https://chromium-review.googlesource.com/532900
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45935}
Port the baseline implementation of Object.prototype.isPrototypeOf to
the CodeStubAssembler, sharing the existing prototype chain lookup logic
with the instanceof / OrdinaryHasInstance implementation. Based on that,
do the same in TurboFan, introducing a new JSHasInPrototypeChain
operator, which encapsulates the central prototype chain walk logic.
This speeds up Object.prototype.isPrototypeOf by more than a factor of
four, so that the code
A.prototype.isPrototypeOf(a)
is now performance-wise on par with
a instanceof A
for the case where A is a regular constructor function and a is an
instance of A.
Since instanceof does more than just the fundamental prototype chain
lookup, it was discovered in Node core that O.p.isPrototypeOf would
be a more appropriate alternative for certain sanity checks, since
it's less vulnerable to monkey-patching. In addition, the Object
builtin would also avoid the performance-cliff associated with
instanceof (due to the Symbol.hasInstance hook), as for example hit
by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
The main blocker was the missing performance of isPrototypeOf, since
it was still a JS builtin backed by a runtime call.
This CL also adds more test coverage for the
Object.prototype.isPrototypeOf builtin, especially when called from
optimized code.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:5269,v8:5989,v8:6483
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2934893002
Cr-Commit-Position: refs/heads/master@{#45925}
TracingCpuProfiler test updates the current plaform while
concurrent marking is running.
This patch also disables stress-incremental-marking for
mjsunit/regress-430201.
BUG=chromium:694255
Change-Id: I85ff538c47bce0300cde3204989ef3f9512b805f
Reviewed-on: https://chromium-review.googlesource.com/533873
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45921}
The function that generated a pre-shifted immediate didn't account for the
instruction with post-shift being unencodable. Fix this by passing
information about the target instruction, and use it to limit the application
of pre-shift.
BUG=chromium:725858
Change-Id: Ia0f70b2ea057975d90162aa6889f15b553acd321
Review-Url: https://codereview.chromium.org/2922173004
Cr-Commit-Position: refs/heads/master@{#45911}
There exists a hidden assumption in V8 that neither foreground nor
background tasks own any memory. For asynchronous WebAssembly
compilation this assumption was wrong, which causes crashes when V8 shut
down before the compilation finished.
With this CL I change the way asynchrous compilation happens. In the
existing implementation each compilation stage provided its own task
which could be spawned either in foreground or background. With this CL
each stage only provides a state, and a generic CompileTask executes on
that state. There exists exactly one state at a time.
To have exactly one state at a time I combined the stages
ExecuteCompilationUnits and FinishCompilationUnits to a single stage. In
addition I removed the WaitForBackgroundTasks stage and added a
CancelableTaskManager to the AsyncCompileJob instead to do the waiting.
BUG=v8:6436
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I2eb61f74235c65524ce720c474eaf99ae7472c81
Reviewed-on: https://chromium-review.googlesource.com/532993
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45908}
Double element types were much slower than Smi/Object previously.
We can box each double in a HeapNumber and push them into a new
FixedArray to save going into the runtime.
Bug: v8:4826, chromium:704966
Change-Id: I7f15d0d636a52760daefed722265c696c1ebb13e
Reviewed-on: https://chromium-review.googlesource.com/531004
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45897}
This feature has been on by default without incident
since V8 5.8.
Bug: v8:5051
Change-Id: I1baf81922efd87e07448955147c50a5ba5a0aa42
Reviewed-on: https://chromium-review.googlesource.com/532214
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45881}
This adds missing support for in-object properties within objects having
the {JSGeneratorObject} type to materialization during deoptimization.
For corner-cases where the implicit generator object is statically known
not to escape, object layout might still be arbitrarily complex.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169,v8:6481
Change-Id: I32f373913d60af64981dc4ed66873cc8a1dbe872
Reviewed-on: https://chromium-review.googlesource.com/530230
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45870}
We were emitting the table index once in the element section instead of
once per element segment. This did not cause failures because we never
had more than one element segment.
This CL fixes this, and adds a test for more than one segment.
R=rossberg@chromium.org
Change-Id: I13923baf3dae383c72760286e24242d0ad55c4db
Reviewed-on: https://chromium-review.googlesource.com/527155
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45857}
This adds support for materializing objects of {JSGeneratorObject} type
during deoptimization. Cases where soft-deopts remove any escaping use
of the implicit generator object can cause it to be escape analyzed.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169
Change-Id: I2ec10b2a509a4f37a456a8ca2fd74b8de2fb55be
Reviewed-on: https://chromium-review.googlesource.com/530847
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45849}
* add functionality to wasm-module-builder.js to emit the module name
in the name section.
* extend WasmModule to store the module name length and offset.
* add functionality to module-decoder.cc to decode the module name.
* use the module name for printing stack traces. more uses should
follow.
* extend one message test to contain a module name.
R=ahaas@chromium.org
Change-Id: I94e6f1f2eb99cb656a92a85bb7afe0742292046f
Reviewed-on: https://chromium-review.googlesource.com/530366
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45846}
This CL removes most occurences of "WASM" from outputs and comments in
the code. They are replaced either by "WebAssembly" or (especially in
comments) "wasm". These are the spellings officially proposed on
http://webassembly.org/.
R=ahaas@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id39fa5e25591678263745a4eab266db546e65983
Reviewed-on: https://chromium-review.googlesource.com/529085
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45824}
ExpressionClassifier was used just for transmitting information back and forth
to DeclareFormalParameters.
As a bonus, we now do the Scope::IsDeclaredParameter check only when we're going
to use the information it produces.
BUG=v8:6092,v8:6474
Change-Id: Ib5ac6a779705caa74e933e1c6f03eaaf0f49bf05
Reviewed-on: https://chromium-review.googlesource.com/455836
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45809}
This removes the ability of the compilation pipeline to invoke the
Crankshaft optimizing compiler for JavaScript functions. Note that in
this state Crankshaft can still be used to compile code stubs.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I0bec7c8ec7c705c13257df43796403a228ea631c
Reviewed-on: https://chromium-review.googlesource.com/527443
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45803}
Both Ignition and TurboFan have been enabled by default for a while.
This just disentangles the implication between those two flags and sets
the --ignition individually. They can now be controlled individually.
R=rmcilroy@chromium.org
BUG=v8:6408
Change-Id: I08eca85120160efa5868b5ca36d1613964ed82eb
Reviewed-on: https://chromium-review.googlesource.com/527637
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45800}
The variant in question was intended to test Crankshaft, which is being
deprecated. Note that the variants 'nooptimization' and 'fullcode' still
test configuration where TurboFan is not active.
R=machenbach@chromium.org
BUG=v8:6408
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I587c3eee7ba511dfc270aab66b546d2532bc635f
Reviewed-on: https://chromium-review.googlesource.com/528133
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45785}
ThrowIfHole bytecodes were handled by introducing deopt points to check
for a hole. To avoid deopt loops a hole check protector was used to
generate control flow if there was a deopt due to a hole. However, the
normal control flow version should be as fast as the deopt version
in general. The deopt version could potentially consume less compile time
but it may not be worth the complexity added. Hence simplifying it to
only construct the control flow.
Bug: v8:6383
Change-Id: Icace11f7a6e21e64e1cebd104496e3f559bc85f7
Reviewed-on: https://chromium-review.googlesource.com/525573
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45783}
Don't treat new prototypes differently depending on how they become a
prototype. This is work towards always keeping prototypes in slow-mode.
Bug: v8:6471
Change-Id: I62de1018e21d91fda3a5da044615f32c718910b1
Reviewed-on: https://chromium-review.googlesource.com/526596
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45781}
This adds block coverage support for simple iteration. For-of and
for-in loops are not yet covered, and we don't yet keep execution counts
for init, cond, and next statements.
BUG=v8:6000
Change-Id: I30b468a2c93f0bb60e857b6632be92920f6857e0
Reviewed-on: https://chromium-review.googlesource.com/527113
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45779}
The two variants "turbofan" and "turbofan_opt" are not part of any of
the default sets of variants that run-tests.py uses. The only way to
trigger execution would be via the --variants flag directly, which our
infrastructure is not doing.
R=machenbach@chromium.org
Change-Id: Ifa58cb4a83a3760ffba73e8b40b417a845f53506
Reviewed-on: https://chromium-review.googlesource.com/526637
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45772}
This CL contains a few pieces:
- A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
graphs, which--when triggered--swizzle the values in the the FrameState to be
parameters to a typically TF-generated builtin that resumes execution to finish
the slow-case functionality.
- Continuation builtins that have special handling in the deoptimizer and their own
new frame type to ensure that the values they need to begin executing can be stashed
away and restored immediately before the builtin is called via a trampoline that runs
when the continuation builtin's frame execution resumes.
- An implementation of Array.prototype.forEach in TurboFan that can be used to
inline it. The inlined forEach implementation uses the checkpoints mechanism
described above to deopt in the middle of the forEach in the cases that optimization
invariants are violated. There is a slightly different continuation stub for each
deopt point in the forEach implementation to ensure the correct side-effects, i.e.
that the deopt of the builtin isn't programmatically observable.
Review-Url: https://codereview.chromium.org/2803853005
Cr-Commit-Position: refs/heads/master@{#45764}
When the slow path for Array.prototype.indexOf calls a Proxy's "has"
trap, it must check afterwards whether an exception was thrown.
BUG=chromium:728813
Change-Id: I998bba6ddcd65adfed2eefb63b3285da60d2a43c
Reviewed-on: https://chromium-review.googlesource.com/527173
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45759}
This removes the test suite variant for stressing Crankshaft from the
list of supported variants. Other stress variants remain untouched.
R=machenbach@chromium.org
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Iad236c2b80a1dea21b8be9b931e6a4e88f3ebcc5
Reviewed-on: https://chromium-review.googlesource.com/527094
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45758}
This cl: https://chromium-review.googlesource.com/509613 changed
CheckNotTaggedHole to not produce any value output. This would mean that
in some cases, we could leak hole on value edges. This violates the
assumption that we cannot see a hole on several operators. Fixing this
back to the original state.
Bug: chromium:730254
Change-Id: I3512930e88dbe15e9d9b4b0d276868f354cc2ae2
Reviewed-on: https://chromium-review.googlesource.com/527033
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45757}
It's possible to build circular objects through the reviver function in
JSON.parse. Recursion needs to check for stack overflows and throw as
needed.
BUG=chromium:729671
Change-Id: I52ccd9ed9fea5829810879f8dd8207043fa6d910
Reviewed-on: https://chromium-review.googlesource.com/525812
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45752}
The inlining of Function.prototype.bind can lead to escape analyzed
bound functions, which weren't handled by the Deoptimizer previously.
BUG=chromium:729573
R=jarin@chromium.org,cbruni@chromium.org
Review-Url: https://codereview.chromium.org/2931483003
Cr-Commit-Position: refs/heads/master@{#45751}
Properly propagate the fact that the function has a statically known name from
parser to SharedFunctionInfo objects. The empty string that has been set as
name before this CL does not help to distinguish cases like:
var o1 = { ''(){} };
var o1 = { [foo()](){} };
or
var o2 = { get ''(){} };
var o2 = { get [foo()](){} };
This is a preliminary step for using different layouts for closure objects with
and without computed names.
TBR=bmeurer@chromium.org, marja@chromium.org
Bug: v8:6459
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I10afa6f4bda7881c3714711a75f720f83c1d875d
Reviewed-on: https://chromium-review.googlesource.com/522073
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45744}
The regression is already fixed. This just adds a regression test to
ensure it will never be reintroduced.
R=ahaas@chromium.org
BUG=chromium:729991
Change-Id: I5cf960cc756cbb7723041bc06a78d6a14c66e241
Reviewed-on: https://chromium-review.googlesource.com/525538
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45739}
This CL implements general infrastructure for block coverage together with
initial support for if-statements.
Coverage output can be generated in lcov format by d8 as follows:
$ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
$ genhtml ~/simple-if.lcov -o ~/simple-if
$ chrome ~/simple-if/index.html
A high level overview of the implementation follows:
The parser now collects source ranges unconditionally for relevant AST nodes.
Memory overhead is very low and this seemed like the cleanest and simplest
alternative.
Bytecode generation uses these ranges to allocate coverage slots and insert
IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
for if-statements). The slot-range mapping is generated here and passed on
through CompilationInfo, and is later accessible through the
SharedFunctionInfo.
The IncBlockCounter bytecode fetches the slot-range mapping (called
CoverageInfo) from the shared function info and simply increments the counter.
We don't collect native-context-specific counts as they are irrelevant to our
use-cases.
Coverage information is finally generated on-demand through Coverage::Collect.
The only current consumer is a d8 front-end with lcov-style output, but the
short-term goal is to expose this through the inspector protocol.
BUG=v8:6000
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
Review-Url: https://codereview.chromium.org/2882973002
Cr-Commit-Position: refs/heads/master@{#45737}
This takes into account the type of the type guard when choosing
representation for a node. To make the representation changes
unambiguous, we pass the restricted type to the changer.
BUG=chromium:726554
Review-Url: https://codereview.chromium.org/2920193004
Cr-Commit-Position: refs/heads/master@{#45734}
Previously Ignition would collect precise Number feedback for binary
operators, but TurboFan would just ignore that and treat it the same as
NumberOrOddball. That however generates a lot of unnecessary code, plus
it defeats redundancy elimination if the same input is also used by
compare operations, which do properly distinguish feedback Number and
NumberOrOddball.
This CL adds the missing bits to connect the existing functionality
properly, i.e. adding the missing BinaryOperationHint and using the
NumberOperationHint::kNumber in the representation selection for tagged
inputs.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2923543003
Cr-Commit-Position: refs/heads/master@{#45732}
When optimizing stores to data properties in literals, we need to first
migrate deprecated maps before we lookup the property access infos for
those.
BUG=chromium:724608
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2930433003
Cr-Commit-Position: refs/heads/master@{#45727}
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole
/ ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks.
In the bytecode-graph builder they are handled by introducing a deopt point
instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant
bytecodes are removed since they are no longer required.
Bug: v8:4280, v8:6383
Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1
Reviewed-on: https://chromium-review.googlesource.com/509613
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45720}
This wraps up the move to explicit APIs, i.e.
instantiateStreaming/compileStreaming.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Icc8280b2b3ad35acb90cc0beebe3acd7581179d7
Reviewed-on: https://chromium-review.googlesource.com/525141
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45719}
TBR=ishell@chromium.org
Bug: v8:6457
Change-Id: I09d7d6ff8460688b7ddf25f733aea73a620db953
Reviewed-on: https://chromium-review.googlesource.com/523037
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45699}
This CL updates the hook for the WebAssembly spec repository, and it
updates the WebAssembly spec tests. The WebAssembly spec tests have to
be updated manually with the tools/wasm/update-wasm-spec-tests.sh
script. Mircea, I saw that you updated the WebAssembly spec repository
last time. Can you please take a look?
UPDATE: I improved the update script slightly, and there is one
additional JS API test we fail now and have to fix eventually.
R=mtrofin@chromium.org
Change-Id: I3c0df9cee64d444147db47daa0c1936edf116173
Reviewed-on: https://chromium-review.googlesource.com/509257
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45692}
Execution tests regress-336820 and regress-678917 finished with error
messages "allocation failure GC in old space requested" and "fatal
javascript OOM in CALL_AND_RETRY_LAST". For successful execution,
parameter max_old_space_size must be increased and this is done inside
tests.
TEST=mjsunit/regress/regress-336820,
mjsunit/regress/regress-678917
BUG=
Review-Url: https://codereview.chromium.org/2907363003
Cr-Original-Commit-Position: refs/heads/master@{#45672}
Committed: 1550c86909
Review-Url: https://codereview.chromium.org/2907363003
Cr-Commit-Position: refs/heads/master@{#45681}
When the input to Function.prototype.bind is a known function, we can
inline the allocation of the JSBoundFunction into TurboFan, which
provides a 2x speed-up for several hot functions in Node streams (as
discovered by Matteo Collina). One of example of this can be found in
https://github.com/nodejs/node/pull/13322, which can be optimized and
made more readable using bind instead of closures.
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2916063002
Cr-Commit-Position: refs/heads/master@{#45679}
Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs.
Changes:
- SuspendGenerator bytecode now takes register list to save.
- ResumeGenerator was split into two bytecodes:
* Resume generator reads the state out and marks the generator as
'executing'.
* RestoreGeneratorRegisters reloads the registers from
the generator.
+ this required adding support for output register list.
- Introduced generator_object_ register in the bytecode generator.
* in subsequent CLs, I will make better use of it, the goal is
to get rid if the .generator_object local variable.
- Taught register optimizer to flush unassigned registers.
BUG=v8:6379
Review-Url: https://codereview.chromium.org/2894293003
Cr-Commit-Position: refs/heads/master@{#45675}
Execution tests regress-336820 and regress-678917 finished with error
messages "allocation failure GC in old space requested" and "fatal
javascript OOM in CALL_AND_RETRY_LAST". For successful execution,
parameter max_old_space_size must be increased and this is done inside
tests.
TEST=mjsunit/regress/regress-336820,
mjsunit/regress/regress-678917
BUG=
Review-Url: https://codereview.chromium.org/2907363003
Cr-Commit-Position: refs/heads/master@{#45672}
Currently x instanceof Map/Set checks cannot take the fast path, since
the Map/Set constructor has dictionary properties. To avoid that, just
forcibly migrate the Map/Set constructor to fast properties again once
it's fully setup in the bootstrapper.
Bug: v8:5717, v8:5902
Change-Id: I23dfd00456c9206a0ca5af71dfbc9236982936fc
Reviewed-on: https://chromium-review.googlesource.com/520578
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45663}
This fixes an issue with ful-codegen where code target entries for the OSR
check were being incorrectly shared. We now explicitly disable sharing of code
target constant pool entries for full-codegen and for calls to builtins from
WASM code, using a scope.
BUG=chromium:725743
Review-Url: https://codereview.chromium.org/2922433002
Cr-Commit-Position: refs/heads/master@{#45661}
Most prototype implementations are not fully supported in the
interpreter. This is the case at least for exception handling, simd, and
atomics. Any function can be redirected to the interpreter though,
either by passing --wasm-interpret-all, or by dynamically redirecting to
the interpreter for debugging.
Making the flags experimental keeps the fuzzer from playing around with
these flags.
Drive-by: Refactor tests which explicitly set the prototype flag to use
a new scope for that.
R=ahaas@chromium.org
BUG=chromium:727584
Change-Id: I67da79f579f1ac93c67189afef40c6524bdd4430
Reviewed-on: https://chromium-review.googlesource.com/519402
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45639}
Causes crashes on canary if there is a GC and the value makes it onto
the stack.
Bug: chromium:727662
Change-Id: I44fa8cf8a83b43d64418896c0a1f5518401b454f
Reviewed-on: https://chromium-review.googlesource.com/519302
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45623}
- Enable aggressive lazy inner funcs (make non-declaration funcs lazy, ie let f =
function() { ... } when --experimental-preparser-scope-analysis is on.
- Turn on variable tracking for lazy top level functions: this makes their inner
functions skippable.
- Test fix for an testing bug uncovered by this work: when restoring the data
for the relevant scope, don't assume it's the outermost scope for which we
have data.
- Fix: if we abort lazy parsing a function, we shouldn't produce any data for
it.
BUG=v8:5516
Change-Id: I0606fbabb5886dc57dbb53ab5f3fb894ff5d032e
Reviewed-on: https://chromium-review.googlesource.com/518165
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45615}
It's extremely difficult to get right: there have been several bugs
related to this feature, especially when combined with
non-simple parameter lists in arrow functions.
BUG=chromium:727218
Change-Id: I97dfbc57a7650199964c5fe99de69143c8e537c2
Reviewed-on: https://chromium-review.googlesource.com/518145
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45603}
This may happen in KeyedStoreIC when the last store via setter deprecates the receiver map.
Bug: chromium:723366
Change-Id: Iff19e50c3761584401340d276ab4eead111883c3
Reviewed-on: https://chromium-review.googlesource.com/517952
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45592}
This time for the current memory size. This call also used to use the
context object stored in the instance, hence it required the instance
to be set. This is no longer the case, so the DCHECKs can just be
removed.
R=ahaas@chromium.org
BUG=chromium:727222
Change-Id: I72a7e3e80c3beb15ecad00c5be068e803456797e
Reviewed-on: https://chromium-review.googlesource.com/517947
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45587}
This widens the range of value output counts to 32 bit on the {Operator}
class. Note that the limit imposed by the parser is 65535 parameters for
each function, but the {Start} node has additional value outputs.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-724153
BUG=chromium:724153
Change-Id: I21b5d947cc2305b255ddbbff6ec1dfa5c02784c7
Reviewed-on: https://chromium-review.googlesource.com/517489
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45573}
For lazy compilation, we encode information about table exports in the
deoptimization data. This information is rebuilt on each instantiation,
so we need to reset it when reusing code objects from another instance.
R=ahaas@chromium.org
BUG=chromium:727219
Change-Id: I90557ef06e692d0a8323223cac26679efcfa408b
Reviewed-on: https://chromium-review.googlesource.com/517945
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45559}
Tests should instead be skipped or fixed.
Existing timeout expectations are either optimistically deleted or replaced by the SLOW keyword.
Change-Id: Ic43f52bf18d0702674c95f9263a109041a1c9cd8
Reviewed-on: https://chromium-review.googlesource.com/518122
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45552}
... to make AsyncFunction subclassing work.
Bug: chromium:725537
Change-Id: I7edf4891e14e01567046e7536b3aa93877111448
Reviewed-on: https://chromium-review.googlesource.com/517087
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45544}
A few tests that would be good to have to verify that the known manifestations
of this bug are resolved.
Previously, the async generator and async function tests would crash. The other
ones never did, but still resulted in the register overwite bug.
BUG=v8:6322
R=adamk@chromium.org
Change-Id: Ic2238227629077de5671d67d18b3bfe018dd23f4
Reviewed-on: https://chromium-review.googlesource.com/514230
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#45524}
Add a protector cell for string bounds checks that is being used to
protect speculative bounds for String.prototype.charCodeAt and
String.prototype.charAt in TurboFan (and Crankshaft). This way we don't
have the diamond in optimized code, which stands in the way of other
optimizations for charCodeAt that are currently being worked on by
petermarshall@.
BUG=v8:6391
TBR=mlippautz@chromium.orgR=petermarshall@chromium.org
Review-Url: https://codereview.chromium.org/2905623003
Cr-Commit-Position: refs/heads/master@{#45514}
Add a sequential string type to the compiler, and transform
charCodeAt on SeqString into SeqStringCharCodeAt.
SeqStringCharCodeAt can handle one and two byte strings.
Bug: v8:6391
Change-Id: I2785257522c28f3b268c9833f5313e9630cb982a
Reviewed-on: https://chromium-review.googlesource.com/509573
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45508}
We're now using explicit APIs.
Bug:
Change-Id: I4a4248e44543f6e7dfcbdc66456e610fb98ff5ee
Reviewed-on: https://chromium-review.googlesource.com/513406
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45500}
Previously the inlining of accessors into try-blocks (i.e. try/catch,
try/finally, for-of, etc.) was disabled in JSNativeContextSpecialization,
which prevented a couple of interesting optimizations, i.e. we end up
with a LOAD_IC in optimized code for this simple example:
class A { get x() { return 1; } }
function foo(a) {
try {
return a.x;
} catch (e) {
return 0;
}
}
foo(new A)
This is now fixed and the accessors are properly rewired into the
handler chain.
BUG=v8:6278,v8:6344,v8:6424
R=jarin@chromium.org
Review-Url: https://codereview.chromium.org/2902533003
Cr-Commit-Position: refs/heads/master@{#45485}
This makes sure that property lookups on the provided imports object are
non-observable to JavaScript. It allows instantiation failures to fall
back to JavaScript proper without accidentally calling accessors twice.
Also accessors might invalidate previous checks done during linking or
throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-crbug-719384
BUG=chromium:719384
Change-Id: I3db2672d2a496110f705d02b82878e70cd5d701f
Reviewed-on: https://chromium-review.googlesource.com/509552
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45481}
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}
The validation of utf8 strings in WebAssembly modules used the character
kBadChar = 0xFFFD to indicate a validation error. However, this
character can appear in a valid utf8 string. This CL fixes this problem
by duplicating some of the code in {Utf8::CalculateValue} and inlining
it directly into Utf8::Validate. Note that Utf8::Validate is used only
for WebAssembly.
Tests for this change are in the WebAssembly spec tests, which I will
update in a separate CL.
R=vogelheim@chromium.org
Change-Id: I8697b9299f3e98a8eafdf193bff8bdff90efd7dc
Reviewed-on: https://chromium-review.googlesource.com/509534
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45476}
This is to avoid ClusterFuzz picking up and using those calls.
With the proper syntax (no whitespace), they are recognized as runtime
calls and will be checked against a whitelist.
R=mstarzinger@chromium.org
BUG=chromium:724459
Change-Id: I5533f066feeb66f622230b12f79f9d227e2b2465
Reviewed-on: https://chromium-review.googlesource.com/509575
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45475}
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 adds a bunch of assertions to CSA, mostly about documenting and checking
parameter types.
Drive-by-change: Removed unused function.
BUG=v8:6325
Review-Url: https://codereview.chromium.org/2847923003
Cr-Original-Commit-Position: refs/heads/master@{#45398}
Committed: b14a981496
Review-Url: https://codereview.chromium.org/2847923003
Cr-Commit-Position: refs/heads/master@{#45443}
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}
As per spec, (https://github.com/WebAssembly/design/pull/1068), we
don't have compile/instantiate overloads anymore, instead, we
have explicitly named members.
This change introduces the new APIs, implements instantiateStreaming
based on compileStreaming, and uses the existing embedder mechanism.
It does not yet remove the functionality from compile/instantiate -
we do that after we adopt the new APIs on the blink side.
Also, it temporarily handles exceptions on the v8 side, which is also
something we'll move to the blink side.
Bug:
Change-Id: I77673b1c0d395dfcf13b2f25464fd5dfd99c8d82
Reviewed-on: https://chromium-review.googlesource.com/508852
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45411}
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}
This adds a bunch of assertions to CSA, mostly about documenting and checking
parameter types.
Drive-by-change: Removed unused function.
BUG=v8:6325
Review-Url: https://codereview.chromium.org/2847923003
Cr-Commit-Position: refs/heads/master@{#45398}
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}
Migrate the Object.keys builtin to the CodeStubAssembler and
use the enum cache backing store whenever it is available. This
gives a nice speedup of 1.5x to 2x when using Object.keys on fast-mode
objects that have (or can have) an enum cache.
R=cbruni@chromium.org
BUG=v8:5269,v8:6405
Review-Url: https://codereview.chromium.org/2853393002
Cr-Commit-Position: refs/heads/master@{#45361}
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}
This makes sure that the order of exports as they appear in asm.js
modules is maintained globally (not just per function) while being
translated to a WASM module.
R=clemensh@chromium.org
TEST=mjsunit/asm/asm-validation
BUG=chromium:720586
Change-Id: I8b26d717ae2f88467d41670bced901f196c7b3fc
Reviewed-on: https://chromium-review.googlesource.com/503708
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45277}
This makes sure that function variables as well as function table
variables are properly typed as immutable, hence assignments to them
should cause validation failures.
R=clemensh@chromium.org
TEST=mjsunit/asm/immutable
BUG=chromium:721271
Change-Id: Ia3f65fd0782ca571ffcf99520fdbd8fc5a359d16
Reviewed-on: https://chromium-review.googlesource.com/503209
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45256}
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}
This makes sure that the checking of stdlib values during module
instantiation is non-observable. It is needed to prevent observable
double evaluation of the involved property loads in case of failures
during instantiation and also fixes some issues with exceptions
happening during property loads.
R=clemensh@chromium.org
TEST=mjsunit/asm/asm-stdlib
BUG=v8:6297
Change-Id: I1d0c371e51bee8186d14fa794fb3f9b7f67e5944
Reviewed-on: https://chromium-review.googlesource.com/501887
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45237}
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}
This fixes cases where falling off the end of a non-void function was
accepted as a valid asm.js module. This led to translation failures in
the WASM code. Only void functions are allowed to fall off the end.
R=clemensh@chromium.org
TEST=mjsunit/asm/return-types
BUG=chromium:719286
Change-Id: I7b1c9ba5381b87a23cf0a2171bee5e5f5e8cd9de
Reviewed-on: https://chromium-review.googlesource.com/500312
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45221}
For small arrays, it's way faster to just move the elements instead of
doing the fairly complex and heavy-weight left-trimming. Crankshaft has
had this optimization for small arrays already; this CL more or less
ports this functionality to TurboFan, which yields a 4x speed-up when
using shift on small arrays (with up to 16 elements).
This should recover some of the regressions reported in the Node.js issues
https://github.com/nodejs/node/issues/12657
and discovered for the syncthrough module using
https://github.com/mcollina/syncthrough/blob/master/benchmarks/basic.js
as benchmark.
R=jarin@chromium.org
BUG=v8:6376
Review-Url: https://codereview.chromium.org/2874453002
Cr-Commit-Position: refs/heads/master@{#45216}
This tests and fixes validation failures caused by assignments to
variables holding functions references (which are all considered
immutable). Such references can come from "stdlib" or "foreign".
R=clemensh@chromium.org
TEST=mjsunit/asm/global-imports
BUG=chromium:719382
Change-Id: Ic02be765e0773a6cc74a54e11a09d42ffb683cb8
Reviewed-on: https://chromium-review.googlesource.com/500188
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45189}
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}
This reverts commit f7c25da680.
Reason for revert: Fixed
Original change's description:
> Revert "Introducing an event loop mechanism for d8."
>
> This reverts commit de964dbe57.
>
> Reason for revert:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/17958
>
> Original change's description:
> > Introducing an event loop mechanism for d8.
> >
> > This mechanism ensures APIs like wasm async complete their work,
> > without requiring use of natives (%APIs).
> >
> > The mechanism is similar to the one used in content_shell,
> > which should allow us to easily port tests in that environment.
> >
> > Review-Url: https://codereview.chromium.org/2842843005
> > Cr-Original-Commit-Position: refs/heads/master@{#44908}
> > Bug:
> > Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
> > Reviewed-on: https://chromium-review.googlesource.com/494968
> > Commit-Queue: Mircea Trofin <mtrofin@google.com>
> > Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#45165}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
>
> Change-Id: Iafec2615d705d1990c57229cab3a988c00b5e12f
> Reviewed-on: https://chromium-review.googlesource.com/498630
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45166}
TBR=bradnelson@chromium.org,machenbach@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org,v8-reviews@googlegroups.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ic3c782e918326e291a6cb9bb349c609e9a340b09
Reviewed-on: https://chromium-review.googlesource.com/498430
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@google.com>
Cr-Commit-Position: refs/heads/master@{#45172}
This reverts commit de964dbe57.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/17958
Original change's description:
> Introducing an event loop mechanism for d8.
>
> This mechanism ensures APIs like wasm async complete their work,
> without requiring use of natives (%APIs).
>
> The mechanism is similar to the one used in content_shell,
> which should allow us to easily port tests in that environment.
>
> Review-Url: https://codereview.chromium.org/2842843005
> Cr-Original-Commit-Position: refs/heads/master@{#44908}
> Bug:
> Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
> Reviewed-on: https://chromium-review.googlesource.com/494968
> Commit-Queue: Mircea Trofin <mtrofin@google.com>
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45165}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,mtrofin@google.com,jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Iafec2615d705d1990c57229cab3a988c00b5e12f
Reviewed-on: https://chromium-review.googlesource.com/498630
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45166}
This mechanism ensures APIs like wasm async complete their work,
without requiring use of natives (%APIs).
The mechanism is similar to the one used in content_shell,
which should allow us to easily port tests in that environment.
Review-Url: https://codereview.chromium.org/2842843005
Cr-Original-Commit-Position: refs/heads/master@{#44908}
Bug:
Change-Id: I9deee0d256a600c60b42902fc8ef8478e5546344
Reviewed-on: https://chromium-review.googlesource.com/494968
Commit-Queue: Mircea Trofin <mtrofin@google.com>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45165}
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}
This CL migrates the CPP builtin to CSA with fast paths for strings
that can be unpacked to direct one-byte strings. Short strings are
handled directly in CSA, others need to call into C for conversion.
Microbenchmarks for "abcd".toLowerCase() show speedups of 2.5x.
BUG=v8:6353,v8:6344
Review-Url: https://codereview.chromium.org/2859203002
Cr-Commit-Position: refs/heads/master@{#45141}
Formal parameters of an arrow function are parsed even if the function
itself is preparsed. It is because we don't know if it is an arrow
function parameter list or just comma separated expression list.
When we parse:
(a, b = (function c() { return a; })())
call to function c may be just part of an assignment in an expression
list, but if it's followed by:
=> { return b; }
It is an arrow function and the call to c is a default parameter.
Before we see the arrow we might have already created a parse task
to parse function c.
BUG=v8:6093
Change-Id: I59a59acfdbbfd808dab1518060748be2addcd54a
Reviewed-on: https://chromium-review.googlesource.com/493347
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45132}
When a virtual object passes by a store node that updates a field to the existing value, then the object and its state were not copied, which lead to the original object being passed on.
If then later the store actually modifies and copies the virtual object, this new copy is not passed down the effect chain, so subsequent nodes still refer to the original virtual object and try to update it once new information flows in.
This conflicts with updates on the node that originally created the virtual object, leading to divergence.
Bug: v8:6345
Change-Id: Iab1ce98a60b48478b343eae765c80bdfcb8ba390
Reviewed-on: https://chromium-review.googlesource.com/496267
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45120}
Removes the do-expression wrapping, modifies BytecodeGenerator change
to enter a class literal's block scope if needed.
This does not solve the actual bug in v8:6322, but helps mitigate it in
simple cases. The bug is caused by BytecodeGenerator not allocating a
large enough array of context registers to hold its entire stack,
allowing non-context registers to be overwritten during PushContext and
PopContext bytecodes.
Nevertheless, I like the idea of not depending on do-expressions when
possible, so I think it's worth doing anyways.
BUG=v8:6322
R=rmcilroy@chromium.org, marja@chromium.org, littledan@chromium.org
Change-Id: I82b7569db2a0eead1694bd04765fc4456c2f1a0a
Reviewed-on: https://chromium-review.googlesource.com/491074
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45110}
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}
Reason for revert:
The decision for the specification was to not have this syntax, and instead the syntax before this patch.
Original issue's description:
> [regexp] Support unicode capture names in non-unicode patterns
>
> This ensures that capture names containing surrogate pairs are parsed
> correctly even in non-unicode RegExp patterns by introducing a new
> scanning mode which unconditionally combines surrogate pairs.
>
> BUG=v8:5437,v8:6192
>
> Review-Url: https://codereview.chromium.org/2791163003
> Cr-Commit-Position: refs/heads/master@{#44466}
> Committed: a8651c5671R=yangguo@chromium.org,jgruber@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:5437,v8:6192
Review-Url: https://codereview.chromium.org/2859933003
Cr-Commit-Position: refs/heads/master@{#45088}
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}
This fixes cases where the omission of return type annotation of calls
to stdlib function was rejected, because a surrounding {fround} call
used to be misinterpreted as an annotation instead of a rounding.
R=clemensh@chromium.org
TEST=mjsunit/asm/call-stdlib
BUG=v8:6127
Change-Id: Idec0ef1740ebf8eda969ff05dd1c90252de87a6b
Reviewed-on: https://chromium-review.googlesource.com/493349
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45057}
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}
The existing CHECK assumed that the source and destination could not
have the same buffer, but they actually can as long as the data
ranges do not overlap within the buffer. Change the check to look for
this more relaxed condition instead.
Moved the check outside of the memcpy case as well, given that it
should also apply for the slower, element-by-element copy as well.
Also use JSTypedArray::element_size() to get the element size instead
of the helper on the FixedTypedArrayBase. This lets us change that
helper back to private again.
Bug: chromium:717022
Change-Id: I2eca1df1e87444c5db397e0b7cf686cefe67d29c
Reviewed-on: https://chromium-review.googlesource.com/493147
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45035}
String inputs would end up in the fast-path, crashing because it
expected an array type. Add the fast path explicitly when the source is
a TypedArray, and let everything else fall back to the generic JS
implementation.
Bug: chromium:715971
Change-Id: Ieec28e93279047d403e00ed2676dc1eda193c033
Reviewed-on: https://chromium-review.googlesource.com/493226
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45034}
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}
The test and associated bug have been fixed a while ago.
BUG=chromium:336820,v8:6325
Review-Url: https://codereview.chromium.org/2851343002
Cr-Commit-Position: refs/heads/master@{#45023}
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}
Give the IC one more chance to get itself into a state that's in
line with Turbofan's capabilities and the following assertOptimized
expectation.
BUG=v8:6101,v8:6325
Review-Url: https://codereview.chromium.org/2848193003
Cr-Commit-Position: refs/heads/master@{#45020}
While parsing top-level code eager functions are skipped just like lazy
ones, but also a parse task is created for each.
The parse tasks are run by the compiler dispatcher and can be executed
either on background thread or in idle time.
After parsing of top-level code finishes it waits for all unfinished
parser tasks - possibly picking up and executing them on current thread.
Afterwards parse task results are stitched together with top-level AST,
in case of failures eager functions are treated just like lazy -
parsing/compilation is retriggered for them in the runtime and proper
errors are generated (performance is not optimized for error case at
all).
BUG=v8:6093
Change-Id: Ie6508211a04b90becfe44139cce1c8ecec386b6e
Reviewed-on: https://chromium-review.googlesource.com/486725
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#45016}
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}
The error thrower did allocate the exception at the moment the error was
detected. For async compilation, this meant in another step than when
it was actually thrown. Since the HandleScope of the exception already
died at that point, this would have lead to memory errors.
With this refactoring, we only store the information needed to generate
the exception in the ErrorThrower, and only generate the exception
object once it is actually needed.
With regression test.
R=ahaas@chromium.org, mtrofin@chromium.org
Also-by: ahaas@chromium.org
Change-Id: Iffcab1f8d1cf5925e3643fcf0729ba9a84c7d277
Reviewed-on: https://chromium-review.googlesource.com/490085
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45000}
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}
The spec requires that a null @@split / @@replace symbol is treated exactly the
same as if it were undefined, i.e. execution should move on to the default
implementation instead of throwing a TypeError.
BUG=v8:6313
Review-Url: https://codereview.chromium.org/2845153002
Cr-Commit-Position: refs/heads/master@{#44959}
With this CL we reduce the difference between directly using a null prototype
in a literal or using Object.create(null).
- The EmitFastCloneShallowObject builtin now supports cloning slow
object boilerplates.
- Unified behavior to find the matching Map and instantiating it for
Object.create(null) and literals with a null prototype.
- Cleanup of literal type parameter of CompileTimeValue, now in sync with
ObjectLiteral flags.
Review-Url: https://codereview.chromium.org/2445333002
Cr-Commit-Position: refs/heads/master@{#44941}
This makes sure that asm.js modules can only be instantiated with a
valid {ArrayBuffer} as the underlying heap buffer for all cases where
accepting anything else would be observably different from JavaScript
proper.
R=clemensh@chromium.org
TEST=mjsunit/asm/asm-memory
BUG=chromium:715505,chromium:715748
Change-Id: I355686200151c5667bf836824de922d657a8d943
Reviewed-on: https://chromium-review.googlesource.com/488521
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44938}
This also fixes incorrect type for fixed array accesses.
BUG=chromium:715651,v8:6309,chromium:715204
Review-Url: https://codereview.chromium.org/2848583002
Cr-Commit-Position: refs/heads/master@{#44926}
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 still doesn't cover all the paths yet, since some paths are
impossible to trigger at this point due to the way the CanInlineCall
predicate works on the AllocationSite, which says multiple things:
- In case of Array(len), the len was always a Smi so far.
- In case of Array(...args), storing the args didn't change the
elements kind.
- In case of Array(len), the len was always less than the initial
maximum fast element array size.
These conditions are tailored towards Crankshaft and don't really
make a lot of sense in the TurboFan world. We'd need more fine
grained protections, which we will achieve by refactoring the Array
constructor.
BUG=chromium:715404,v8:6262
TBR=machenbach@chromium.org
Review-Url: https://codereview.chromium.org/2843033002
Cr-Commit-Position: refs/heads/master@{#44901}
For holey Smi and double source arrays, we would go to the general
case, which is much slower than before. We already check that there
are no prototype chain changes in IterableToListCanBeElided, and
there is no JS-code run between that check and the copying of the
elements, so we can safely check for the hole and convert it to
undefined, which is then converted to 0/NaN appropriately for the
given TypedArray.
Bug: chromium:713570,chromium:711275
Change-Id: I5b21c915907d71eebb73b7b1eea8eb58b4a5436d
Reviewed-on: https://chromium-review.googlesource.com/485520
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44899}
Reason for revert:
Field representation is not preserved
Original issue's description:
> [turbofan] Set proper representation for initial arguments length.
>
> The JSArgumentsObject::length representation is initially Smi, so we can
> record that on the initial map and use it to optimize the accesses in
> TurboFan based on that. Similar for JSSloppyArgumentsObject::caller.
>
> BUG=v8:6262
> R=yangguo@chromium.org
>
> Review-Url: https://codereview.chromium.org/2810333004
> Cr-Commit-Position: refs/heads/master@{#44644}
> Committed: 5eec7df9b3TBR=yangguo@chromium.org,bmeurer@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=v8:6262
Review-Url: https://codereview.chromium.org/2825323002
Cr-Commit-Position: refs/heads/master@{#44893}
This makes sure that the observable property order of the module export
maintains insertion order. Now that properties are configurable, we no
longer need to reverse the export processing.
R=clemensh@chromium.org
TEST=mjsunit/asm/asm-validation
BUG=chromium:715420
Change-Id: Ib2024254c07bdad7fee1cf2fa0bd3e847721f5b5
Reviewed-on: https://chromium-review.googlesource.com/488022
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44891}
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}
Although we currently only support up to 1GB memory, we want to raise
this issue in the future. This test illustrates several issues we need
to be sure to fix first.
Bug: v8:6306
Change-Id: I362b7a9e51e8eb33a50e3b172a6f01d41995c3cb
Reviewed-on: https://chromium-review.googlesource.com/487047
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44876}
Also add more local variables to regress-v8-6077 to force
register spill on platform with 32 float registers.
BUG=
Review-Url: https://codereview.chromium.org/2822073003
Cr-Commit-Position: refs/heads/master@{#44865}
This reverts commit 56a6fda316.
Reason for revert: Makes tsan flaky:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/15038
Original change's description:
> [parser] Inital parallel parse tasks implementation.
>
> While parsing top-level code eager functions are skipped just like lazy
> ones, but also a parse task is created for each.
>
> The parse tasks are run by the compiler dispatcher and can be executed
> either on background thread or in idle time.
> After parsing of top-level code finishes it waits for all unfinished
> parser tasks - possibly picking up and executing them on current thread.
> Afterwards parse task results are stitched together with top-level AST,
> in case of failures eager functions are treated just like lazy -
> parsing/compilation is retriggered for them in the runtime and proper
> errors are generated (performance is not optimized for error case at
> all).
>
> BUG=v8:6093
>
> Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
> Reviewed-on: https://chromium-review.googlesource.com/483439
> Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jochen Eisinger <jochen@chromium.org>
> Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44849}
TBR=marja@chromium.org,vogelheim@chromium.org,jochen@chromium.org,wiktorg@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6093
Change-Id: I17e689efee7d216d28a94a5c8147022ae7e830dd
Reviewed-on: https://chromium-review.googlesource.com/486883
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44859}
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}
While parsing top-level code eager functions are skipped just like lazy
ones, but also a parse task is created for each.
The parse tasks are run by the compiler dispatcher and can be executed
either on background thread or in idle time.
After parsing of top-level code finishes it waits for all unfinished
parser tasks - possibly picking up and executing them on current thread.
Afterwards parse task results are stitched together with top-level AST,
in case of failures eager functions are treated just like lazy -
parsing/compilation is retriggered for them in the runtime and proper
errors are generated (performance is not optimized for error case at
all).
BUG=v8:6093
Change-Id: I718dd2acc8a70ae1b09c2dea2616716605d7b05d
Reviewed-on: https://chromium-review.googlesource.com/483439
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44849}
Some of these tests pass the pattern as a string, and in this case
there's a subtle distinction between
"/\u{0041}/" // Unicode escape interpreted in string literal.
and
"/\\u{0041}/" // Unicode escape interpreted by regexp parser.
Extend these tests to check both cases.
Thanks littledan@ for pointing this out.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2839923002
Cr-Commit-Position: refs/heads/master@{#44840}
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}
We already have an optimization to constant-fold access to an object's
prototype via the special __proto__ accessor (specified in appendix B).
We can use the same optimization to also constant-fold accesses to an
object's prototype via the official Object.getPrototypeOf function.
Also add the optimization for Reflect.getPrototypeOf, which is
equivalent for object inputs.
This is commonly used by Babel to implement various new language
features, for example subclassing and certain property lookups.
R=yangguo@chromium.org
BUG=v8:6292
Review-Url: https://codereview.chromium.org/2841463002
Cr-Commit-Position: refs/heads/master@{#44788}
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}
This also removes a broken optimization regarding immutable (i.e. const)
global variables. For now mutable and immutable global variables are
treated the same and hence copied during module initialization.
R=rossberg@chromium.org
TEST=mjsunit/asm/global-imports
BUG=v8:6279
Change-Id: I020fc12036dc534f5a62fb43f5c6fdb252314e62
Reviewed-on: https://chromium-review.googlesource.com/483360
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44763}
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}
Move JSOrdinaryHasInstance lowering to JSNativeContextSpecialization,
which was previously mostly done in JSTypedLowering (for no reason).
Add new logic to the lowering to constant-fold OrdinaryHasInstance
checks when the map of the left-hand side and the "prototype" of the
right-hand side is known. This address the performance issue with the
(base) class constructors generated by Babel, i.e.:
function _classCallCheck(instance, Constructor) {
if (!(instance instanceof Constructor)) {
throw new TypeError("Cannot call a class as a function");
}
}
var C = function C() { _classCallCheck(this, C); };
for
class C {}
Also ensure that a known constructor being used inside an instanceof
get's a proper initial map on-demand.
BUG=v8:6275
R=mstarzinger@chromium.org
Review-Url: https://codereview.chromium.org/2827013002
Cr-Commit-Position: refs/heads/master@{#44727}
When adding or overwriting properties of an object, the generic
keyed store stub must check if that property's name might have
an associated protector (e.g. the ArraySpeciesProtector) and
take the slow path if so to ensure that the protector is updated
as needed.
BUG=v8:6269
Review-Url: https://codereview.chromium.org/2821213004
Cr-Commit-Position: refs/heads/master@{#44726}
This includes a fastpath in the ElementsAccessor for the source
array being a JSArray with FastSmi or FastDouble packed kinds. This
is probably a pretty common usage, where an array is passed in as
a way of initializing the TypedArray at creation (as there is not other
syntax to do this). e.g. new Float64Array([1.0, 1.0, 1.0]) for some
sort of vector application.
BUG= v8:5977
Change-Id: Ice4ad9fc29f56b1c4b0b30736a1330efdc289003
Reviewed-on: https://chromium-review.googlesource.com/465126
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44722}
This fixes source position tracking within the "increment" expression of
a for-statement. The old {StashCode} method was inherently incompatible
with side tables like the source position table, as it would leave them
untouched while mutating the bytecode stream. It was hence trimmed down
to {DeleteCode}.
R=bradnelson@chromium.org
BUG=v8:6127
Change-Id: I7a5ff60cd5334208c44b165c8b54144d9ae83209
Reviewed-on: https://chromium-review.googlesource.com/480301
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44714}
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}
The feature is not quite ready for getting ClusterFuzzed.
BUG=v8:5516
Change-Id: I90a42f950727c8ecf46cb2987c9a459b2ba1f5a7
Reviewed-on: https://chromium-review.googlesource.com/480400
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44693}
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}
This changes the message from
"method_name is not generic"
to
"method_name requires that 'this' be a primitive_name object"
BUG=v8:6206
Review-Url: https://codereview.chromium.org/2814043006
Cr-Commit-Position: refs/heads/master@{#44683}
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}
Today, the semantics of:
WebAssembly.instantiate
and
WebAssembly.compile().then(new WebAssemblyInstance)
are subtly different, to the point where attempting the proposed
change uncovered bugs.
In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.
This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.
- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2806073002
Cr-Original-Commit-Position: refs/heads/master@{#44592}
Committed: 7829af3275
Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44669}
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}
e3246ad69c
removed some redundancies in yield and yield*.
In particular:
- AsyncGeneratorRawYield becomes unnecessary, and is deleted in this CL
- Parser::RewriteYieldStar() is updated to perform the IteratorValue() algorithm as appropriate
BUG=v8:6187, v8:5855
R=rmcilroy@chromium.org, adamk@chromium.org, littledan@chromium.org, vogelheim@chromium.org
Change-Id: I05e8429b9cbd4531c330ee53a05656b90162064c
Reviewed-on: https://chromium-review.googlesource.com/471806
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44649}
Currently we count optimizations to decide to disable optimization, and
count deopts to detect this decision and allow re-enabling optimizations
after a while.
However, throwing out TurboFan OSR code and GC optimized code evictions
do not count as deopts, which means that the optimization count
increases without increasing the deopt count. This increased optimization
count disables further optimization -- which is bad, because these are
not "true" deopts -- and can stop the optimization from being re-enabled,
because the deopt count can't go high enough.
Instead, we now only ever look at deopts to disable/re-enable
optimization, and opt counts are only used for naming log files and in
tests.
Change-Id: I0c7d6be497545449a38cf952cd2f007ee51982ba
Reviewed-on: https://chromium-review.googlesource.com/468811
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44647}
This fixes the validation of "|0" annotations of call sites that are
used to indicate a "signed" return type of functions. We use lookahead
during call validation and request deferred validation as part of the
actual OR-expression. Special care has to be taken to get precedence
levels of all involved operators right.
R=clemensh@chromium.org
TEST=mjsunit/asm/call-annotation
BUG=v8:6183
Change-Id: If0586f669e7cee26a13425b0fd9f41098e852d68
Reviewed-on: https://chromium-review.googlesource.com/475871
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44639}
The condition only applies in unicode mode, where any lone surrogates
are desugared into a character class (and will not be considered in this
optimization). Non-unicode mode treats lone surrogates exactly like
any other codepoint.
BUG=chromium:711092
Review-Url: https://codereview.chromium.org/2808403006
Cr-Commit-Position: refs/heads/master@{#44638}
In eval scripts, the source code position can be 0 rather
than greater than 0.
Add regression test.
Drive-by fix: unrelated typo.
Bug: 707223
Change-Id: If52c0736daac3ad42ac6d324eb8ec5f1798f6f5a
Reviewed-on: https://chromium-review.googlesource.com/476630
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44637}
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}
It's required by the spec -- and observable -- that the index be validated
before the conversion of the value(s) via ToInteger.
The previous implementation also had an old test for validating the atomic
index, which has now been switched to ToIndex.
This also exposed an issue in the ia32 code generator: cmpxchg_b requires a
byte register, but the ia32 instruction selector was ensuring that the
new_value was a byte register, not the TempRegister. This change forces the
temp register to use edx, which always can be used as a byte register (dl).
This is the same behavior as currently used in UseByteRegister.
BUG=v8:4614
R=jarin@chromium.org,jkummerow@chromium.org
Review-Url: https://codereview.chromium.org/2814753003
Cr-Commit-Position: refs/heads/master@{#44626}
Unfortunately, this test cannot test that a function was really skipped (i.e.,
not parsed).
BUG=v8:5516
Change-Id: I8db5027d2216a95cc012ceae8e17554095cc1d4f
Reviewed-on: https://chromium-review.googlesource.com/457037
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44615}
Reason for revert:
Roll blocker: https://bugs.chromium.org/p/chromium/issues/detail?id=710824
Original issue's description:
> [wasm] instantiate expressed in terms of compile
>
> Today, the semantics of:
>
> WebAssembly.instantiate
>
> and
>
> WebAssembly.compile().then(new WebAssemblyInstance)
>
> are subtly different, to the point where attempting the proposed
> change uncovered bugs.
>
> In the future, it's possible that .instantiate actually have different
> semantics - if we pre-specialized to the provided ffi, for example.
> Right now that's not the case.
>
> This CL:
> - gets our implementation closer to what developers may write using
> the compile -> new Instance alternative, in particular wrt promise
> creation. By reusing code paths, we uncover more bugs, and keep
> maintenance cost lower.
>
> - it gives us the response-based WebAssembly.instantiate implicitly.
> Otherwise, we'd need that same implementation on the blink side. The
> negative is maintenance: imagine if the bugs I mentioned could only be
> found when running in Blink.
>
> BUG=chromium:697028
>
> Review-Url: https://codereview.chromium.org/2806073002
> Cr-Commit-Position: refs/heads/master@{#44592}
> Committed: 7829af3275TBR=bradnelson@chromium.org,ahaas@chromium.org,adamk@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2810203002
Cr-Commit-Position: refs/heads/master@{#44614}
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 change mirrors the semantics for derived class constructors. This
change doesn't affect non class constructors.
This change could potentially break web compat. More details:
https://github.com/tc39/ecma262/pull/469
Bug=v8:5536
Change-Id: I519599949523733332d0b35e4f8d9ecb01cac495
Reviewed-on: https://chromium-review.googlesource.com/461225
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44594}
Today, the semantics of:
WebAssembly.instantiate
and
WebAssembly.compile().then(new WebAssemblyInstance)
are subtly different, to the point where attempting the proposed
change uncovered bugs.
In the future, it's possible that .instantiate actually have different
semantics - if we pre-specialized to the provided ffi, for example.
Right now that's not the case.
This CL:
- gets our implementation closer to what developers may write using
the compile -> new Instance alternative, in particular wrt promise
creation. By reusing code paths, we uncover more bugs, and keep
maintenance cost lower.
- it gives us the response-based WebAssembly.instantiate implicitly.
Otherwise, we'd need that same implementation on the blink side. The
negative is maintenance: imagine if the bugs I mentioned could only be
found when running in Blink.
BUG=chromium:697028
Review-Url: https://codereview.chromium.org/2806073002
Cr-Commit-Position: refs/heads/master@{#44592}
The test "assertThrows(builder.instantiate)" threw a TypeError before,
which made the test pass, but not because of the feature we wanted to
test.
This CL fixes the test to call builder.instantiate correctly, and also
tests for the correct error message.
Drive-by fix: Fix {expected} and {found} parameters in assertThrows.
R=ahaas@chromium.org
Change-Id: I11c0f63885cc14a36559e637aea60a9da6f1bb8f
Reviewed-on: https://chromium-review.googlesource.com/472886
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44584}
Reason for revert:
Reland with tests marked as off in no-i18n mode
Original issue's description:
> Revert of [date] Add ICU backend for timezone info behind a flag (patchset #17 id:320001 of https://codereview.chromium.org/2724373002/ )
>
> Reason for revert:
> Breaks noi18n:
> https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/13314
>
> Original issue's description:
> > [date] Add ICU backend for timezone info behind a flag
> >
> > This patch implements a timezone backend which is based on ICU, rather
> > than operating system calls. It can be turned on by passing the
> > --icu-timezone-data flag. The goal here is to take advantage of ICU's
> > data, which is more complete than the data that some system calls expose.
> > For example, without any special code, this patch fixes the time zone
> > of Lord Howe Island to have a correct 30 minute DST offset, rather than
> > 60 minutes as the OS backends assume it to have.
> >
> > Unfortunately, the parenthized timezone name in Date.prototype.toString()
> > differs across platforms. This patch chooses the long timezone name,
> > which matches Windows behavior and might be the most intelligible, but
> > the web compatibility impact is unclear.
> >
> > BUG=v8:6031,v8:2137,v8:6076
> >
> > Review-Url: https://codereview.chromium.org/2724373002
> > Cr-Commit-Position: refs/heads/master@{#44562}
> > Committed: b213f23990
>
> TBR=ulan@chromium.org,jshin@chromium.org,jgruber@chromium.org,littledan@chromium.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:6031,v8:2137,v8:6076
>
> Review-Url: https://codereview.chromium.org/2811103002
> Cr-Commit-Position: refs/heads/master@{#44565}
> Committed: 13ad508110TBR=ulan@chromium.org,jshin@chromium.org,jgruber@chromium.org,machenbach@chromium.org
BUG=v8:6031,v8:2137,v8:6076
Review-Url: https://codereview.chromium.org/2813863002
Cr-Commit-Position: refs/heads/master@{#44575}
A really slight change in behaviour introduced by
395b2e3b2f
Just swaps the order that properties are loaded from an iterator result
object in the various Async-from-Sync Iterator methods.
Fixes for the test262 tests have been submitted already (https://github.com/tc39/test262/pull/961).
BUG=v8:5855, v8:6242
R=littledan@chromium.org, jwolfe@igalia.com,
Change-Id: I1ff0e1b7758c126d02aec27d67ceeb15b91c06cf
Reviewed-on: https://chromium-review.googlesource.com/474087
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44572}
The spec proposal has been updated to drop contributory binary
properties such as `Other_ID_Start` and `Other_ID_Continue`.
This patch reverts commit 26e5d0129c and
adds tests to ensure these properties are not supported.
R=
BUG=v8:4743
Review-Url: https://codereview.chromium.org/2809143003
Cr-Commit-Position: refs/heads/master@{#44569}
Reason for revert:
Breaks noi18n:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/13314
Original issue's description:
> [date] Add ICU backend for timezone info behind a flag
>
> This patch implements a timezone backend which is based on ICU, rather
> than operating system calls. It can be turned on by passing the
> --icu-timezone-data flag. The goal here is to take advantage of ICU's
> data, which is more complete than the data that some system calls expose.
> For example, without any special code, this patch fixes the time zone
> of Lord Howe Island to have a correct 30 minute DST offset, rather than
> 60 minutes as the OS backends assume it to have.
>
> Unfortunately, the parenthized timezone name in Date.prototype.toString()
> differs across platforms. This patch chooses the long timezone name,
> which matches Windows behavior and might be the most intelligible, but
> the web compatibility impact is unclear.
>
> BUG=v8:6031,v8:2137,v8:6076
>
> Review-Url: https://codereview.chromium.org/2724373002
> Cr-Commit-Position: refs/heads/master@{#44562}
> Committed: b213f23990TBR=ulan@chromium.org,jshin@chromium.org,jgruber@chromium.org,littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6031,v8:2137,v8:6076
Review-Url: https://codereview.chromium.org/2811103002
Cr-Commit-Position: refs/heads/master@{#44565}
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}
This patch implements a timezone backend which is based on ICU, rather
than operating system calls. It can be turned on by passing the
--icu-timezone-data flag. The goal here is to take advantage of ICU's
data, which is more complete than the data that some system calls expose.
For example, without any special code, this patch fixes the time zone
of Lord Howe Island to have a correct 30 minute DST offset, rather than
60 minutes as the OS backends assume it to have.
Unfortunately, the parenthized timezone name in Date.prototype.toString()
differs across platforms. This patch chooses the long timezone name,
which matches Windows behavior and might be the most intelligible, but
the web compatibility impact is unclear.
BUG=v8:6031,v8:2137,v8:6076
Review-Url: https://codereview.chromium.org/2724373002
Cr-Commit-Position: refs/heads/master@{#44562}
This patch implements the runtime semantics of dynamic import.
We create a new ASTNode so that we can pass the JSFunction closure() to
the runtime function from which we get the script_url.
d8 implements the embedder logic required to load and evaluate the modules.
The API is mostly implemented as specified.
BUG=8:5785
Review-Url: https://codereview.chromium.org/2703563002
Cr-Commit-Position: refs/heads/master@{#44551}
Other_ID_Start and Other_ID_Continue are not supported by ICU, so for
now we implement these manually as special binary property classes.
R=jgruber@chromium.org
BUG=v8:4743
Review-Url: https://codereview.chromium.org/2808803002
Cr-Commit-Position: refs/heads/master@{#44549}
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}
According to the spec the copy step is defined iteratively and with
@@species we can create a TypedArray which shares the buffer with the
receiver which in turn prevents us from using memcpy.
Bug: v8:6223
Change-Id: If1bad085ea1d022bf3fb2cffc81645b2f7f56346
Reviewed-on: https://chromium-review.googlesource.com/471409
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44520}
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 spec requires that we use IterableToList, which we skipped for
some arrays as an optimization. We can't skip this for arrays with
objects though, because the objects may mutate the array during
the copying step via valueOf side effects.
Also clean up the implementation to use a runtime function rather
than a builtin as the helper. Also reverses the result of the helper
because I think it is a bit more intuitive that way.
Bug: v8:6224
Change-Id: I9199491abede4479785df6d9068331bc2d6e9c5e
Reviewed-on: https://chromium-review.googlesource.com/471986
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44507}
This revealed a bug in the TypedArray(typedArray) constructor when the arg is backed by a SharedArrayBuffer.
Also install the species getter and add a test, since it's not tested in
test262 presently.
BUG=v8:5983,v8:5984
R=adamk@chromium.org
Review-Url: https://codereview.chromium.org/2798403004
Cr-Commit-Position: refs/heads/master@{#44500}
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}
The spec requires truncation while ToUint32 originally rounded down.
This also adds a bunch of test cases to check edge case behavior.
BUG=v8:6212
Review-Url: https://codereview.chromium.org/2805783003
Cr-Commit-Position: refs/heads/master@{#44487}
This ensures that capture names containing surrogate pairs are parsed
correctly even in non-unicode RegExp patterns by introducing a new
scanning mode which unconditionally combines surrogate pairs.
BUG=v8:5437,v8:6192
Review-Url: https://codereview.chromium.org/2791163003
Cr-Commit-Position: refs/heads/master@{#44466}
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}
The following aspects were changed for the reland:
* The DeferredHandleScope is supposed with a specific pattern,
i.e. allocate handles in a normal HandleScope and then
reopen them in the DeferredHandleScope.
* Set the native_context when it is used in a task.
Change-Id: Ia42c46ec6bc73179cb1f458e36658414ff85cc23
Reviewed-on: https://chromium-review.googlesource.com/468809
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44434}
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}
This extends the test coverage for source position tracking of ToNumber
conversion to also test conversion to "double" type. It also fixes the
discovered inconsistencies. Note that the conversion to "float" remains
untested as imported functions are not allowed have "float" return type.
R=clemensh@chromium.org
TEST=mjsunit/wasm/asm-wasm-exception-in-tonumber
BUG=v8:6127
Change-Id: I6c59b7a24456a585a814f19a86eb9447ac5098ab
Reviewed-on: https://chromium-review.googlesource.com/467251
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44409}
IdentifierStart::Is and IdentifierContinue::Is both return true for '\'.
The reason for this is lost to history.
Special-case '\' in the regexp parser to handle this.
BUG=v8:5437,v8:5868
Review-Url: https://codereview.chromium.org/2795093003
Cr-Commit-Position: refs/heads/master@{#44396}
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}
Update according to new spec change at
https://github.com/tc39/ecma262/pull/856
- Call ToNumber only once in BUILTIN
- Remove unused FillNumberSlowPath
- FillImpl assumes obj_value->IsNumber() is true
- Update test
Bug:v8:5929,chromium:702902
Change-Id: Ic83e6754d043582955b81c76e68f95e1c6b7e901
Reviewed-on: https://chromium-review.googlesource.com/465646
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44373}
Make sure that we call the destructors on all embedded object by
replacing the WasmInterpreterInternals::Delete method by an actual
destructor. This way, the compiler automatically calls destructors on
all embedded objects, in particular the IdentityMap in the CodeMap.
This change also requires to release managed objects *before*
tearing down the heap, because the wasm interpreter, referenced via
Managed<>, contains global handles. When those are destroyed, the
isolate still needs to be intact.
Drive-by: Fix include guard in managed.h.
R=ahaas@chromium.org, ulan@chromium.org, mvstanton@chromium.org
BUG=v8:5822
Change-Id: I9a067f037e013c84e4d697a1e913b27c683bb529
Reviewed-on: https://chromium-review.googlesource.com/466187
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44368}
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}
Return a structured objet with the type profile
information.
Move the test from message to mjsunit.
BUG=v8:5933
Change-Id: I3e1c592697924d87f82d46b0ddbdb6d82d9c8467
Reviewed-on: https://chromium-review.googlesource.com/464847
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44364}
This fixes the name stored with functions where the declaration was
hoisted above the actual function definition. It also extends test
coverage and emits proper source position mapping for such cases.
R=clemensh@chromium.org
TEST=mjsunit/wasm/asm-wasm-stack
BUG=v8:6127
Change-Id: I675a98b244fe2157925e799b5c46b7f6bd53c9da
Reviewed-on: https://chromium-review.googlesource.com/466247
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44361}
This adds test coverage for the source position tracking of function
table calls in asm.js and fixes the discovered issues. It also fixes
function start positions (used by errors thrown at stack checks).
R=clemensh@chromium.org
TEST=mjsunit/wasm/asm-wasm-stack
BUG=v8:6127,v8:6166
Change-Id: Id6ab6dc72bcedb0d838eed315e2a05fbc59039f4
Reviewed-on: https://chromium-review.googlesource.com/465949
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44348}
The byte_length field of the TypedArray is not set to 0 on neutering,
but JSArrayBufferView::byte_length() returns 0 if WasNeutered() is
true. We should use the length property here instead.
We can just short-circuit if the length is 0. Added checks to the
memcpy path that assert length and neutered status are sane.
Bug:chromium:707472,chromium:707595,chromium:707364,chromium:707410
Change-Id: Ia1dec53f175357673012cbbc5e2fc40207e03623
Reviewed-on: https://chromium-review.googlesource.com/465987
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44336}
This adds support for tracking token positions in the asm.js scanner and
uses these positions to emit a mapping from WASM to asm.js positions.
Note that the mapping is still incomplete (some call sites are not yet
covered).
R=clemensh@chromium.org
TEST=debugger/debug/wasm/asm-debug
BUG=v8:6127
Change-Id: Ic8aad1a85e7d9e19da2eec523fcc73d4984afcc8
Reviewed-on: https://chromium-review.googlesource.com/466046
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44335}
A DCHECK was failing if we unwind an activation which is not the
bottom-most. This CL fixes this and adds a test for this.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: Ib69116b4c45a7b2a0d6cab97ad984dfdcda55918
Reviewed-on: https://chromium-review.googlesource.com/464788
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44332}
Previously, named captures (and related functionality) were restricted to
unicode-mode regexps.
This CL extends that support to non-unicode patterns. Named groups are
supported regardless of the mode, and named back-references are supported if
the regexp is in unicode mode or if it contains a named capture (otherwise '\k'
is treated as an identity escape).
BUG=v8:5437,v8:6192
Review-Url: https://codereview.chromium.org/2788873002
Cr-Commit-Position: refs/heads/master@{#44324}
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}
Numbered back-references that occur before the referenced capture
trigger an internal mini-parser that looks ahead in the pattern and
counts capturing groups.
This updates the mini-parser to correctly handle named captures.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2792523002
Cr-Commit-Position: refs/heads/master@{#44303}
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}
grow_memory was working from test cases, but not in combination with
compiled code. This CL makes the effect of grow_memory executed either
in the interpreter or compiled code always be reflected in both
execution environments.
It also adds a %RedirectToWasmInterpreter runtime function for testing
this interaction.
R=ahaas@chromium.orgCC=gdeepti@chromium.org
BUG=v8:5822
Change-Id: I3e7c184c42ef655d1c30d2e0dddad7fb783455fc
Reviewed-on: https://chromium-review.googlesource.com/463506
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44297}
Add a limit to the number of nested call frames in the C++ wasm
interpreter.
Both the size of the value stack as well as the size of the block stack
are limited per call frame. Thus, a limit on only the call frame stack
is enough to limit the overall memory consumption of one interpreter
instance.
R=ahaas@chromium.org
BUG=v8:5822
Change-Id: If9f7e547cd1d003bc2ae3c7586ece6b3cf3be587
Reviewed-on: https://chromium-review.googlesource.com/463486
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44296}
The dotAll flag changes behavior of the dot '.' character to match every
possible single character instead of excluding certain line terminators.
The implementation is staged behind --harmony-regexp-dotall.
Spec proposal: https://github.com/mathiasbynens/es-regexp-dotall-flag
BUG=v8:6172
Review-Url: https://codereview.chromium.org/2780173002
Cr-Commit-Position: refs/heads/master@{#44295}
Currently, async generators are stringified the same way normal
Generators are. This change prefixes async generator methods with
"async *", and other async generator functions with
"async function* ".
BUG=v8:5855
R=adamk@chromium.org, littledan@chromium.org, jwolfe@igalia.com
Change-Id: Ia809fad64caac4464dbc9f7fa7728584d0f67832
Reviewed-on: https://chromium-review.googlesource.com/463526
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44278}
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}
BUG=v8:4958
Change-Id: Id02d36fce76eed54a5a3d348dbac2ea7d43f4ef3
Reviewed-on: https://chromium-review.googlesource.com/462336
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44275}
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 regression comes from attempting to serialize a module with memory
requirements after instantiation - which is what happens in common emscripten
scenarios, where the module is obtained from WebAssembly.instantiate(buffer). We then try and serialize the JSArrayBuffer
representing the instance memory. That operation fails.
Added regression test and also extended the test to cover the other 2
instance-specific values - globals and tables.
Added a discussion on WasmCompiledModule (comments) explaining design decisions.
BUG=chromium:705562
Review-Url: https://codereview.chromium.org/2784453002
Cr-Commit-Position: refs/heads/master@{#44250}
- Introduce new struct AsyncGeneratorRequest, which holds
information pertinent to resuming execution of an
AsyncGenerator, such as the Promise associated with the async
generator request. It is intended to be used as a singly
linked list, and holds a pointer to the next item in te queue.
- Introduce JSAsyncGeneratorObject (subclass of
JSGeneratorObject), which includes several new internal fields
(`queue` which contains a singly linked list of
AsyncGeneratorRequest objects, and `await_input` which
contains the sent value from an Await expression (This is
necessary to prevent function.sent (used by yield*) from
having the sent value observably overwritten during
execution).
- Modify SuspendGenerator to accept a set of Flags, which
indicate whether the suspend is for a Yield or Await, and
whether it takes place on an async generator or ES6
generator.
- Introduce interpreter intrinsics and TF intrinsic lowering for
accessing the await input of an async generator
- Modify the JSGeneratorStore operator to understand whether or
not it's suspending for a normal yield, or an AsyncGenerator
Await. This ensures appropriate registers are stored.
- Add versions of ResumeGeneratorTrampoline which store the
input value in a different field depending on wether it's an
AsyncGenerator Await resume, or an ordinary resume. Also modifies
whether debug code will assert that the generator object is a
JSGeneratorObject or a JSAsyncGeneratorObject depending on the
resume type.
BUG=v8:5855
R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org,
littledan@chromium.org, neis@chromium.orgTBR=marja@chromium.org
Change-Id: I9d58df1d344465fc937fe7eed322424204497187
Reviewed-on: https://chromium-review.googlesource.com/446961
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44240}
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}
Fix a few items broken during review of scanner + parser:
* Make the scanner retain stale newline state on a rewind (as otherwise it must be able to correctly rewind that too, though it doesn't need it). (Probably should revisit).
* Change StashCode in the builder skip to the zero case, as it crashes for some reason (added TODO).
Also fix:
* Drop test based on constant expression evaluation in main parser
* Support constant defined based on existing constant.
* Type constants as signed.
* Added a check that all used functions are defined eventually.
* Zone allocate strings for simplicity (TODOs to refactor better).
BUG=v8:6090
BUG=v8:4203
R=mstarzinger@chromium.org,marja@chromium.org,vogelheim@chromium.org
Review-Url: https://codereview.chromium.org/2771183002
Cr-Original-Commit-Position: refs/heads/master@{#44200}
Committed: be0dbdd679
Review-Url: https://codereview.chromium.org/2771183002
Cr-Commit-Position: refs/heads/master@{#44203}
Reason for revert:
Fails on gc-stress.
Original issue's description:
> [wasm][asm.js] Fix and enable several asm.js tests with the new parser.
>
> Fix a few items broken during review of scanner + parser:
> * Make the scanner retain stale newline state on a rewind (as otherwise it must be able to correctly rewind that too, though it doesn't need it). (Probably should revisit).
> * Change StashCode in the builder skip to the zero case, as it crashes for some reason (added TODO).
>
> Also fix:
> * Drop test based on constant expression evaluation in main parser
> * Support constant defined based on existing constant.
> * Type constants as signed.
> * Added a check that all used functions are defined eventually.
> * Zone allocate strings for simplicity (TODOs to refactor better).
>
> BUG=v8:6090
> BUG=v8:4203
> R=mstarzinger@chromium.org,marja@chromium.org,vogelheim@chromium.org
>
> Review-Url: https://codereview.chromium.org/2771183002
> Cr-Commit-Position: refs/heads/master@{#44200}
> Committed: be0dbdd679TBR=clemensh@chromium.org,bradnelson@google.com,marja@chromium.org,mstarzinger@chromium.org,vogelheim@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:6090
Review-Url: https://codereview.chromium.org/2782613002
Cr-Commit-Position: refs/heads/master@{#44201}
Fix a few items broken during review of scanner + parser:
* Make the scanner retain stale newline state on a rewind (as otherwise it must be able to correctly rewind that too, though it doesn't need it). (Probably should revisit).
* Change StashCode in the builder skip to the zero case, as it crashes for some reason (added TODO).
Also fix:
* Drop test based on constant expression evaluation in main parser
* Support constant defined based on existing constant.
* Type constants as signed.
* Added a check that all used functions are defined eventually.
* Zone allocate strings for simplicity (TODOs to refactor better).
BUG=v8:6090
BUG=v8:4203
R=mstarzinger@chromium.org,marja@chromium.org,vogelheim@chromium.org
Review-Url: https://codereview.chromium.org/2771183002
Cr-Commit-Position: refs/heads/master@{#44200}
This implements support for named captures in
RegExp.prototype[@@replace] for when the replaceValue is not callable.
Named captures can be referenced from replacement strings by using the
"$<name>" syntax. A couple of examples:
let re = /(?<fst>.)(?<snd>.)/u;
"abcd".replace(re, "$<snd>$<fst>") // "bacd"
"abcd".replace(re, "$2$1") // "bacd" (numbered refs work as always)
"abcd".replace(re, "$<snd") // SyntaxError (unterminated named ref)
"abcd".replace(re, "$<42$1>") // "cd" (invalid name)
"abcd".replace(re, "$<thd>") // "cd" (non-existent name)
"abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>") // "cd" (non-matched capture)
Support is currently behind the --harmony-regexp-named-captures flag.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2775303002
Cr-Original-Commit-Position: refs/heads/master@{#44171}
Committed: 17f13863b6
Review-Url: https://codereview.chromium.org/2775303002
Cr-Commit-Position: refs/heads/master@{#44182}
Reason for revert:
Invalid DCHECKs for non-matched groups.
Original issue's description:
> [regexp] Named capture support for string replacements
>
> This implements support for named captures in
> RegExp.prototype[@@replace] for when the replaceValue is not callable.
>
> Named captures can be referenced from replacement strings by using the
> "$<name>" syntax. A couple of examples:
>
> let re = /(?<fst>.)(?<snd>.)/u;
> "abcd".replace(re, "$<snd>$<fst>") // "bacd"
> "abcd".replace(re, "$2$1") // "bacd" (numbered refs work as always)
> "abcd".replace(re, "$<snd") // SyntaxError (unterminated named ref)
> "abcd".replace(re, "$<42$1>") // "cd" (invalid name)
> "abcd".replace(re, "$<thd>") // "cd" (non-existent name)
> "abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>") // "cd" (non-matched capture)
>
> Support is currently behind the --harmony-regexp-named-captures flag.
>
> BUG=v8:5437
>
> Review-Url: https://codereview.chromium.org/2775303002
> Cr-Commit-Position: refs/heads/master@{#44171}
> Committed: 17f13863b6TBR=yangguo@chromium.org,littledan@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2776293003
Cr-Commit-Position: refs/heads/master@{#44180}
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 implements support for named captures in
RegExp.prototype[@@replace] for when the replaceValue is not callable.
Named captures can be referenced from replacement strings by using the
"$<name>" syntax. A couple of examples:
let re = /(?<fst>.)(?<snd>.)/u;
"abcd".replace(re, "$<snd>$<fst>") // "bacd"
"abcd".replace(re, "$2$1") // "bacd" (numbered refs work as always)
"abcd".replace(re, "$<snd") // SyntaxError (unterminated named ref)
"abcd".replace(re, "$<42$1>") // "cd" (invalid name)
"abcd".replace(re, "$<thd>") // "cd" (non-existent name)
"abcd".replace(/(?<fst>.)|(?<snd>.)/u, "$<snd>") // "cd" (non-matched capture)
Support is currently behind the --harmony-regexp-named-captures flag.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2775303002
Cr-Commit-Position: refs/heads/master@{#44171}
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}
This implements support for named captures in
RegExp.prototype[@@replace] for when the replaceValue is callable.
In that case, the result.groups object is passed to the replacer
function as the last argument.
BUG=v8:5437
Review-Url: https://codereview.chromium.org/2764343004
Cr-Commit-Position: refs/heads/master@{#44142}
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}
ToNumber for Oddball/String has no side-effect, no need to go
through %Typearray%.prototype.fill slow path.
BUG=v8:5929,chromium:702902
Review-Url: https://codereview.chromium.org/2769673002
Cr-Commit-Position: refs/heads/master@{#44129}
This helper is used directly when constructing from an object with
a length, as well as by ConstructByIterable and ByTypedArray.
BUG=v8:5977
Change-Id: I18a4829c2a22a6099cf3b0824ea1f698bfbf1917
Reviewed-on: https://chromium-review.googlesource.com/456707
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44116}
