- Removes IsRegExp check and special handling when false
- Removes MatchAllIterator
- Extracts previously inlined CreateRegExpStringIterator
- Update comments to match spec text and numbering
Bug: v8:6890
Change-Id: Ie81757a499acc77910f029835fb042e70d86d83d
Reviewed-on: https://chromium-review.googlesource.com/c/1317830
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57488}
This is to prevent errors like:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/8792
The error code suggests the OS killed the tests due to OOM. The time it took
suggests OS paging. Fewer tests in parallel should mitigate this.
NOTRY=true
Change-Id: I847058cfb02a9a36795581df47760d921d695141
Reviewed-on: https://chromium-review.googlesource.com/c/1333674
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57486}
Port bd0a7fd64c
Original Commit Message:
This reduces the build steps after touching counters.h from 710 to 191, thus
detaching counters.h from the giant include cluster.
R=marja@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:7490,v8:8238
LOG=N
Change-Id: I7694a21856c228c6d0335c1f1e5e9177c96cc7da
Reviewed-on: https://chromium-review.googlesource.com/c/1333940
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57485}
This CL is an experiment to get more performance data from the perf-bots
and will likely lead to regressions. The try-bots (see patcheset 9)
indicate some regressions, but it doesn't seem too bad.
Change-Id: Ia173ab20ee2a4904663db0f4ca2ffb196b203c77
Reviewed-on: https://chromium-review.googlesource.com/c/1319763
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57483}
Now you can type:
tools/torque/format-torque.py -i src/builtins/*.tq
to format all the torque files in a particular directory. Is handy.
TBR=danno@chromium.org
Bug: v8:7793
Change-Id: Ifba85c4db553e19a65b87217fd2f670698c6b2c9
Reviewed-on: https://chromium-review.googlesource.com/c/1333679
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57482}
With this we can just shortcircuit parsing if we see an incorrect
Token::COMMA or Token::COLON when parsing class literals.
Change-Id: Idd0c0c33b035b821ed23174f9cb1b12616a2a621
Reviewed-on: https://chromium-review.googlesource.com/c/1333678
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57481}
This reverts commit 96a17c03da.
Reason for revert: Caused the tree to close
Original change's description:
> [Torque] format-torque.py accepts wildcards
>
> Now you can type:
> tools/torque/format-torque.py -i src/builtins/*.tq
>
> to format all the torque files in a particular directory. Is handy.
>
> Bug: v8:7793
> Change-Id: I334b2c555c63fd7864636ebfd83a2631a5d44806
> Reviewed-on: https://chromium-review.googlesource.com/c/1333671
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57479}
TBR=danno@chromium.org,mvstanton@chromium.org
Change-Id: Ib531bd2f20f438ef95b657eb86356ee724fa5b39
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/1333677
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57480}
Now you can type:
tools/torque/format-torque.py -i src/builtins/*.tq
to format all the torque files in a particular directory. Is handy.
Bug: v8:7793
Change-Id: I334b2c555c63fd7864636ebfd83a2631a5d44806
Reviewed-on: https://chromium-review.googlesource.com/c/1333671
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57479}
This is important for transient types, which might be invalidated
in a loop syntactically below the vulnerable use.
Bug: v8:7793
Change-Id: Ia97c03282eefbc44d54beb8edc61f5d44af2c947
Reviewed-on: https://chromium-review.googlesource.com/c/1331547
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57478}
This refactoring hides the fact that some wrappers are first generated
in the GC'ed heap and then copied into the native module. It is a first
step towards avoiding the redundant copy.
R=clemensh@chromium.org
Change-Id: I531fa42e8b4c210948d306624007348a39b981e0
Reviewed-on: https://chromium-review.googlesource.com/c/1333673
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57477}
In the process, move the rest of the implementation PLabels into the
CodeAssembler for consistency.
Change-Id: I56872d9fc756db066f0d13d87aeb55ec04de2495
Reviewed-on: https://chromium-review.googlesource.com/c/1329687
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57474}
Use same value to rethrow as was used before this change. This doesn't
appear to be explicitly tested anywhere, but the behavior should stay
unchanged nevertheless.
Change-Id: Idaed90a143e9775746f034190918065897094acb
Reviewed-on: https://chromium-review.googlesource.com/c/1329684
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57472}
This reduces the build steps after touching counters.h from 710 to 191, thus
detaching counters.h from the giant include cluster.
BUG=v8:7490,v8:8238
Change-Id: I0c7e707fb945e293f8a5604cc8da438cd35b3210
Reviewed-on: https://chromium-review.googlesource.com/c/1329695
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57468}
Just moving code around a bit.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: I6a9f9dab41360e9a0d8249fe77260788151cd88b
Reviewed-on: https://chromium-review.googlesource.com/c/1333411
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57466}
We were outputting the address of the WasmCodeManager instead of the
native module.
R=ahaas@chromium.org
Change-Id: I70f0aca4ef9126b91fcc3716570bfc69e71d27c7
Reviewed-on: https://chromium-review.googlesource.com/c/1326024
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57465}
For some reason the C++ compiler fails to realise that next_ cannot
change on entry into Scan from Next, and re-loads it, creating what
looks like a data dependency that stalls the next instruction.
Passing through a cached next_ value cleans up the generated code.
Change-Id: Iab62ed1890a3a720e5fa90a90e802305e3d55a82
Reviewed-on: https://chromium-review.googlesource.com/c/1331551
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57464}
Use a flag int instead of bit fields in LiteralBuffer, so that
cache the output of next() in Scanner::Scan() so that it doesn't get
reloaded between LiteralBuffer::Drop() calls.
LiteralBuffer: :Drop can set a single value rather than masking. Also,
Change-Id: I977703488ac41e3b091f46ce0840e7c464639073
Reviewed-on: https://chromium-review.googlesource.com/c/1331548
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57463}
We're fetching the symbols anyway, so we might as well use those instead in the
preparser.
Change-Id: Ie937c755690cdd7b15e8486aa9680d530eff602e
Reviewed-on: https://chromium-review.googlesource.com/c/1332296
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57460}
An oversight in my previous change (3b64764b1d) could
cause a CHECK failure.
Bug: chromium:904707
Change-Id: Ie5f1c500bddc00741b889f78ae9ecd9af581ba5c
Reviewed-on: https://chromium-review.googlesource.com/c/1333409
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57459}
Previously, the following call sequence was always made when creating resulting
subsetted TypedArray:
1) TFJ TypedArrayPrototypeSubArray
2) TFS TypedArrayConstructor
3) TFS CreateTypedArray
This CL, skips #2 and goes straight to #3 when the default constructor (builtin) is
safe to use (IsPrototypeTypedArrayPrototype and
!IsTypedArraySpeciesProtectorCellInvalid).
Local TypedArrays/SubarrayNoSpecies microbenchmark shows ~35-40% improvement...
BEFORE
TypedArrays-SubarrayNoSpecies(Score): 1033530
TypedArrays-SubarrayNoSpecies(Score): 1018490
TypedArrays-SubarrayNoSpecies(Score): 1037030
AFTER
TypedArrays-SubarrayNoSpecies(Score): 1439030
TypedArrays-SubarrayNoSpecies(Score): 1417540
TypedArrays-SubarrayNoSpecies(Score): 1405980
Bug: v8:7161
Change-Id: I356dace36570aa161ffe208a57a80e46714121a2
Reviewed-on: https://chromium-review.googlesource.com/c/1331154
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57458}
It's not sufficient to check the NoElements protector because that
doesn't guard against the array having a custom prototype.
Bug: v8:8449
Change-Id: I843815466a1e4ae197a2b76eec62d04cdc2d619d
Reviewed-on: https://chromium-review.googlesource.com/c/1332232
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57457}
This matches the pre-torque behavior when the receiver's length
was greater than the max array length.
Bug: chromium:902672
Change-Id: Icf8ae3a1a4acc0680ce1b709f5b3372892337203
Reviewed-on: https://chromium-review.googlesource.com/c/1330921
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57456}
This CL updates DetachableVector to store the data at a known place
instead of in an std::vector<>, so that builtins can update it directly.
Bug: v8:8124
Change-Id: Iba5fb2e9d4e0ddc689d0f7eeaea40bc3218edf3a
Reviewed-on: https://chromium-review.googlesource.com/c/1297783
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57452}
See the WebAssembly bulk memory proposal here:
https://github.com/WebAssembly/bulk-memory-operations
This initial CL adds a wasm experimental flag:
`--experimental-wasm-bulk-memory`, and also parsing of passive segments.
A passive segment is one that is not copied into the table/memory on
instantiation, but instead later via the `{table,memory}.init`
instructions.
The binary format of passive data segments is unlikely to change, but
the format for passive element segments may change (see
https://github.com/WebAssembly/bulk-memory-operations/pull/39).
Bug: v8:7747
Change-Id: I2a7fb9bc7648a722a8c4aab4185c68d3d0843858
Reviewed-on: https://chromium-review.googlesource.com/c/1330015
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57451}
because for some reason gdb does not want to execute
job *handle
anymore.
Bug: v8:8238
Change-Id: I9b632f5d34048b80e1f9542de963f738f1afb613
Reviewed-on: https://chromium-review.googlesource.com/c/1332230
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57449}
With this change, the return value is not baked into the translations
for lazy deoptimization point. Instead, the translation contains
a position where the return value(s) should be written by
the deoptimizer. The deoptimizer then constructs the frame as it
would look before and during the call and then overwrites the relevant
slot(s) with the return value(s) from the callee.
The advantage is that we do not run the risk of overwriting captured
objects in the tranlations. Moreover, the translations correctly reflect
the frame during the call (e.g., if it is inspected by the debugger or
if an exception is thrown and no value is returned).
Bug: chromium:902608
Change-Id: I03824f0efec3dd476feacbcc0ab6102c3e6c94bf
Reviewed-on: https://chromium-review.googlesource.com/c/1329203
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57446}
