- 13 Nov, 2018 9 commits
-
-
Toon Verwaest authored
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/1332296Reviewed-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}
-
Georg Neis authored
An oversight in my previous change (3b64764b) could cause a CHECK failure. Bug: chromium:904707 Change-Id: Ie5f1c500bddc00741b889f78ae9ecd9af581ba5c Reviewed-on: https://chromium-review.googlesource.com/c/1333409Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57459}
-
peterwmwong authored
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}
-
Georg Neis authored
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/1332232Reviewed-by:
-
peterwmwong authored
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:
-
Michael Achenbach authored
This skips more tests sensitive to optimization state on gc fuzzer. Failure links: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20NumFuzz%20-%20debug/3620 https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20NumFuzz%20-%20TSAN/3584 https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20NumFuzz%20-%20TSAN/3564 NOTRY=true TBR=sigurds@chromium.org Change-Id: Iba8f475178b87a10b7cf793c65b16132ed2f1a1b Reviewed-on: https://chromium-review.googlesource.com/c/1332294Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#57455}
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I52660eeda1bd299953793af9af1395f47e89072e Reviewed-on: https://chromium-review.googlesource.com/c/1331155 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57454}
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/81ffd00..8af70c5 Rolling v8/third_party/android_tools: https://chromium.googlesource.com/android_tools/+log/130499e..6fecaa5 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/f2c3502..0cf6ee7 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/ddbeac1..332c9ff Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/31f2d26..fa8094f TBR=machenbach@chromium.org,hablich@chromium.org,sergiyb@chromium.org Change-Id: Ic70fa8509b5fc87f37f30b2081a92807518b4fe2 Reviewed-on: https://chromium-review.googlesource.com/c/1332869 Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#57453}
-
tzik authored
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:
-
- 12 Nov, 2018 31 commits
-
-
Ben Smith authored
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}
-
Frank Tang authored
Bug: v8:8438 Change-Id: I7b45f75c790c007d69f61d13f2ac8936b9efb67d Reviewed-on: https://chromium-review.googlesource.com/c/1331988Reviewed-by:
-
Igor Sheludko authored
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}
-
Junliang Yan authored
Port fe61cd64 R=jkummerow@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Idee62637817fea020f809772de96b43c2a39cadd Reviewed-on: https://chromium-review.googlesource.com/c/1331832Reviewed-by:
Joran Siu <joransiu@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#57448}
-
Junliang Yan authored
Port d0562944 R=mythria@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: Ib27ea8c66e3fa37d13d0e10553f1caf10c9d527b Reviewed-on: https://chromium-review.googlesource.com/c/1332107Reviewed-by:
-
Jaroslav Sevcik authored
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}
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: I413ce57f7fa91cef2445995ca22650477f92b0df Reviewed-on: https://chromium-review.googlesource.com/c/1321892Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Frank Tang authored
Bug: v8:8424 Change-Id: Ic4f5b229dca4c3a802701aaa6e2093e280739a78 Reviewed-on: https://chromium-review.googlesource.com/c/1328646Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#57444}
-
Junliang Yan authored
R=joransiu@ca.ibm.com Change-Id: I09f57abe9a0fdd8d42c9f52b745a0f9957b67e58 Reviewed-on: https://chromium-review.googlesource.com/c/1330264Reviewed-by:
-
Sathya Gunasekaran authored
Bug: v8:6443, v8:7569 Change-Id: Ie1733198af76d07ac4601c5058af531701434fef Reviewed-on: https://chromium-review.googlesource.com/c/1331549Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#57442}
-
Clemens Hammacher authored
R=gdeepti@chromium.org Change-Id: I8fabe18101b7e23b5e2971fedd0bd3591783dc85 Reviewed-on: https://chromium-review.googlesource.com/c/1329699Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57441}
-
Sathya Gunasekaran authored
Bug: v8:6443, v8:7569 Change-Id: Ia7f0550500b19e93d78983db2e20d020bc0ff164 Reviewed-on: https://chromium-review.googlesource.com/c/1329700Reviewed-by:
-
Sathya Gunasekaran authored
in SmallOrderedHashTable Bug: v8:6443, v8:7569 Change-Id: I14572b1acc30df45d0554ee7e8e129da85791529 Reviewed-on: https://chromium-review.googlesource.com/c/1329698Reviewed-by:
-
Sathya Gunasekaran authored
Bug: v8:6443, v8:7569 Change-Id: Iee039eddd07a7bbc38c8e9f7deca00d5183e702a Reviewed-on: https://chromium-review.googlesource.com/c/1329697Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#57438}
-
Ben L. Titzer authored
This CL splits the backend of TurboFan off into its own directory, without changing namespaces. This makes ownership management a bit more fine-grained with a logical separation. R=mstarzinger@chromium.org,jarin@chromium.org,adamk@chromium.org Change-Id: I2ac40d6ca2c4f04b8474b630aae0286ecf79ef42 Reviewed-on: https://chromium-review.googlesource.com/c/1308333 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
1) For the code space estimate, exclude everything except code. 2) Add some static code size per function. 3) Add some static code size per module. 4) Include signature zone memory. R=mstarzinger@chromium.org Change-Id: Ifa9ac347edf98c2e63ab3201a64ac2e0a3de28e5 Reviewed-on: https://chromium-review.googlesource.com/c/1118263Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#57436}
-
Clemens Hammacher authored
After the first decoder error, the streaming processor should not be called again. To enforce this, reset the {processor_} field. This also makes the {ok_} field redundant. Note that this refactoring is also necessary for a future CL which makes the {StreamingProcessor} keep the {AsyncCompileJob} alive. By resetting the processor, we also remove that link. R=ahaas@chromium.org Bug: v8:7921 Change-Id: I42f5ed26a8f26c3dc8db5676557a0d82021e132e Reviewed-on: https://chromium-review.googlesource.com/c/1329179 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: -
Jakob Gruber authored
This removes unused code (macros.py, runtime functions). As IS_VAR is now unused we can remove support from the parser. Bug: v8:7624 Change-Id: Ia1c5e23f4c2caa85310d3f9a557218fc52d200f2 Reviewed-on: https://chromium-review.googlesource.com/c/1329696Reviewed-by:
-
Igor Sheludko authored
Bug: v8:8182 Change-Id: I9c83428b54764db99e83a6bf6ef556b68fd546b0 Reviewed-on: https://chromium-review.googlesource.com/c/1329694Reviewed-by:
-
Sathya Gunasekaran authored
... to OrderedNameDict Bug: v8:6443, v8:7569 Change-Id: Ic952c88e3256935391707032320913069020b045 Reviewed-on: https://chromium-review.googlesource.com/c/1329682Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#57432}
-
Sathya Gunasekaran authored
Specialize FindEntry for OrderedNameDictionary Bug: v8:6443, v8:7569 Change-Id: I776415fde6bc2ea292b645fbca6952c7bb09d89d Reviewed-on: https://chromium-review.googlesource.com/c/1329962Reviewed-by:
-
Sathya Gunasekaran authored
This is the larger dictionary specialized for Name. To be used as a property backing store. More methods and tests will be added in the future as it reaches parity with NameDictionary. Bug: v8:6443, v8:7569 Change-Id: I8f5d88b2f6f4e14d4851548566ffa9f59535358b Reviewed-on: https://chromium-review.googlesource.com/c/1329204Reviewed-by:
-
Clemens Hammacher authored
I just ran into this when creating a test case. The huge spread caused a RangeError (stack overflow). It's not causing problems for the tests we currently have, but let's fix it anyway. R=ahaas@chromium.org Change-Id: Ib67f059f2981ccc6239ba4ae05611e20eb3aa191 Reviewed-on: https://chromium-review.googlesource.com/c/1329177 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
Fixes building in MSVS with -std:c++17 Refs: https://en.cppreference.com/w/cpp/utility/functional/unary_function Change-Id: Ibb05b6810cae029aae33957f3eb52cc3a9e4863e Reviewed-on: https://chromium-review.googlesource.com/c/1227322 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#57428}
-
Toon Verwaest authored
Now that identifiers in the preparser also carry their string, we can simply check that rather than relying on a weird "keyword". Dropping __proto__ as a keyword allows us to delist '_' as keyword character. Change-Id: I775df25f77a84de92a60790ca665f16d52abf4bf Reviewed-on: https://chromium-review.googlesource.com/c/1329692 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Clemens Hammacher authored
gcc 4.8 fails to compile an {std::atomic::compare_exchange_strong} with {memory_order_acq_rel} with this error: error: invalid failure memory model for ‘__atomic_compare_exchange’ This makes our gcov bot fail: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20-%20gcov%20coverage/16053 According to the documentation, giving a single {memory_order_acq_rel} is equivalent to specifying {memory_order_acq_rel} as success memory order and {memory_order_acquire} for failure. This CL refactors the code to do this explicitly. R=ulan@chromium.org CC=machenbach@chromium.org Bug: v8:8238 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel Change-Id: Idcc69ee4b4ac53edc4fd1aa28eac7377f08044ce Reviewed-on: https://chromium-review.googlesource.com/c/1329693Reviewed-by: -
Daniel Clifford authored
Change-Id: Ie7f3cec3ae6541f46b3f43c83bd9d53de7614d20 Reviewed-on: https://chromium-review.googlesource.com/c/1329689 Commit-Queue: Daniel Clifford <danno@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Now that we have no more do-expressions, we don't need to reparent variables and declarations anymore. However, it's still possible that temporaries were implicitly allocated. We still need to move those. Bug: chromium:904255 Change-Id: Ia8a90eb822b9db123ffb0bad58e4b720c1452d9f Reviewed-on: https://chromium-review.googlesource.com/c/1329685Reviewed-by:
-
Toon Verwaest authored
Otherwise we may look into the invalid string literal later. Bug: chromium:903527 Change-Id: Ieeb3807bd05e532224e04a59878f5dac24e19579 Reviewed-on: https://chromium-review.googlesource.com/c/1329691 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
-
Georg Neis authored
A missing negation (typo in previous refactoring) had effectively disabled this optimization. Bug: chromium:904104 Change-Id: I3f8d26c7594fcaa762e0a9c992b4cb0bf1bc53f6 Reviewed-on: https://chromium-review.googlesource.com/c/1329690Reviewed-by:
-
Toon Verwaest authored
Bug: chromium:904275 Change-Id: I82712f70954246c16846f44bb9e8dc6e60e73d83 Reviewed-on: https://chromium-review.googlesource.com/c/1329686Reviewed-by:
-
