- 04 Sep, 2017 17 commits
-
-
Jaroslav Sevcik authored
We encode the reachability/liveness in the placement. After we prepare use counts, the kUnknown placement means that the noe is unreachable. Bug: v8:5267 Change-Id: Iad27159508f0aefb812b6394a257055f789fbe13 Reviewed-on: https://chromium-review.googlesource.com/646247 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47795}
-
Clemens Hammacher authored
Rename Managed::New to Managed::From (since it takes ownership of an existing object), and re-introduce Managed::Allocate, which allocates a new object and stores it in a Managed. R=titzer@chromium.org Change-Id: I20b0750697fbe7d56d3816b19919c31e389278b3 Reviewed-on: https://chromium-review.googlesource.com/645806Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47794}
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4 Reviewed-on: https://chromium-review.googlesource.com/647888Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47793}
-
Michael Achenbach authored
This reverts commit 84c2dfce. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/14876 Original change's description: > Remove weak-list of optimized JS functions. > > This CL removes the weak-list of JS functions from the context > and all the code that iterares over it. This list was being used > mainly during deoptimization (for code unlinking) and during > garbage collection. Removing it will improve performance of > programs that create many closures and trigger many scavenge GC > cycles. > > No extra work is required during garbage collection. However, > given that we no longer unlink code from JS functions during > deoptimization, we leave it as it is, and on its next activation > we check whether the mark_for_deoptimization bit of that code is > set, and if it is, than we unlink it and jump to lazy compiled > code. This check happens in the prologue of every code object. > > We needed to change/remove the cctests that used to check > something on this list. > > Working in x64, ia32, arm64, arm, mips64 and mips. > > Bug: v8:6637 > Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 > Reviewed-on: https://chromium-review.googlesource.com/600427 > Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47790} TBR=mstarzinger@chromium.org,jarin@chromium.org,leszeks@chromium.org,bmeurer@chromium.org,jupvfranco@google.com Change-Id: Ia4f1a8acf6ca5cd5c74266437a03d854b3739af2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6637 Reviewed-on: https://chromium-review.googlesource.com/647540Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#47792}
-
Clemens Hammacher authored
After this CL, we will enable cpplint checks for this directory on presubmit: https://chromium-review.googlesource.com/647807 R=mstarzinger@chromium.org Change-Id: Ie85e876a7245cc5c8d5bf9348c8841040a8edbe9 Reviewed-on: https://chromium-review.googlesource.com/647552Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47791}
-
Juliana Franco authored
This CL removes the weak-list of JS functions from the context and all the code that iterares over it. This list was being used mainly during deoptimization (for code unlinking) and during garbage collection. Removing it will improve performance of programs that create many closures and trigger many scavenge GC cycles. No extra work is required during garbage collection. However, given that we no longer unlink code from JS functions during deoptimization, we leave it as it is, and on its next activation we check whether the mark_for_deoptimization bit of that code is set, and if it is, than we unlink it and jump to lazy compiled code. This check happens in the prologue of every code object. We needed to change/remove the cctests that used to check something on this list. Working in x64, ia32, arm64, arm, mips64 and mips. Bug: v8:6637 Change-Id: I7f192652c8034b16a9ea71303fa8e78cda3c48f3 Reviewed-on: https://chromium-review.googlesource.com/600427 Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47790}
-
jgruber authored
Our current deserializers (startup & partial) use a system of static memory reservations: required memory is determined at serialization time, which we then request before deserialization and dole out as-needed during deserialization. Lazy builtin deserialization needs a bit more flexibility. On the one hand, the amount of required memory varies since --lazy-deserialization can be switched on and off at runtime. On the other, builtin deserialization has been made order-independent, and we can encounter references to builtins before they have been deserialized. Both problems are solved by dynamically allocating required memory and initializing the builtins table with the (yet uninitialized) builtin Code objects. Bug: v8:6624 Change-Id: Iee90992e91adb4ab45dae1acc81f64a108d12584 Reviewed-on: https://chromium-review.googlesource.com/647748 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47789}
-
Marja Hölttä authored
These will tight-loop scanning primitives. BUG=v8:6092 Change-Id: I9bf0f1952755bbede3c545c45fe2c4a210548171 Reviewed-on: https://chromium-review.googlesource.com/647526Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47788}
-
Clemens Hammacher authored
This reverts commit 6daf3c77. Reason for revert: Need to fix violations in test/fuzzer first. Original change's description: > [presubmit] Include test/common and test/fuzzer in cpplint > > These directories probably just did not exist when the cpplint paths > were defined. > > R=machenbach@chromium.org > CC=mstarzinger@chromium.org > > Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642 > Reviewed-on: https://chromium-review.googlesource.com/647807 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47786} TBR=machenbach@chromium.org,mstarzinger@chromium.org,clemensh@chromium.org Change-Id: Ie20f0e9ef521c8da0c928bee241427fad694a440 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/647593Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47787}
-
Clemens Hammacher authored
These directories probably just did not exist when the cpplint paths were defined. R=machenbach@chromium.org CC=mstarzinger@chromium.org Change-Id: Ia6b641b3c106d86ceafb0c70b44ca241b4c80642 Reviewed-on: https://chromium-review.googlesource.com/647807Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47786}
-
Clemens Hammacher authored
For readability. Also make them constexpr, which allows to use them in other constexpr contexts. R=mstarzinger@chromium.org Change-Id: Ia9ea9b4fb044bd1a011da887409bfbcbf6298fec Reviewed-on: https://chromium-review.googlesource.com/647627Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47785}
-
Clemens Hammacher authored
This allows to reuse this logic in the wasm baseline compiler to determine the location of our parameters. R=mstarzinger@chromium.org CC=titzer@chromium.org Bug: v8:6600 Change-Id: I86e4d425d1c8aa35f0f722d311a2bd830b951d0a Reviewed-on: https://chromium-review.googlesource.com/647628Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47784}
-
Jakob Gruber authored
DeserializeLazy must be deserialized eagerly since it implements the lazy deserialization mechanism. Wasm currently requires their builtins to be immovable; and since we can only efficiently allocate immovable code objects at deserialization time, wasm builtins must be eager-loaded for now. Bug: v8:6624 Change-Id: I9aae60385d4b08a34a52e12711ee1a492476f7cf Reviewed-on: https://chromium-review.googlesource.com/647707Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47783}
-
Mostyn Bramley-Moore authored
Bug: chromium:746958 Change-Id: I5df144055d1918bf26acba648e07646150249d94 Reviewed-on: https://chromium-review.googlesource.com/647549Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Cr-Commit-Position: refs/heads/master@{#47782}
-
Yang Guo authored
This reverts commit c0e4e79b. Reason for revert: Isolate tests fail. https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/20200/steps/Check%20-%20isolates/logs/stdio Original change's description: > [d8] implement setTimeout. > > R=ahaas@chromium.org, jarin@chromium.org > > Bug: v8:6770 > Change-Id: Iebf4dc9f2dd75079c5362e02d859c48e2113cf20 > Reviewed-on: https://chromium-review.googlesource.com/643067 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47780} TBR=yangguo@chromium.org,jarin@chromium.org,ahaas@chromium.org Change-Id: I7abdedd7f5f4215d3df7b63f6656e78e1c4f9ea8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6770 Reviewed-on: https://chromium-review.googlesource.com/647592Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47781}
-
Yang Guo authored
R=ahaas@chromium.org, jarin@chromium.org Bug: v8:6770 Change-Id: Iebf4dc9f2dd75079c5362e02d859c48e2113cf20 Reviewed-on: https://chromium-review.googlesource.com/643067Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47780}
-
Yuki Shiino authored
As Blink needs a way to delete a property without running a script, make Object::Delete use ENTER_V8_NO_SCRIPT if the receiver object is not a JSProxy. Also makes Object::DeletePrivate use ENTER_V8_NO_SCRIPT, too. Bug: chromium:728583 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ib37959764b99a68d730d1bbc6dba410106d4f452 Reviewed-on: https://chromium-review.googlesource.com/608348Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#47779}
-
- 03 Sep, 2017 1 commit
-
-
Ben Noordhuis authored
See: https://github.com/nodejs/llnode/issues/117 Change-Id: Icc2830c8e9096610df33ffdc2f89e74cb1b35662 Reviewed-on: https://chromium-review.googlesource.com/618986Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Ben Noordhuis <info@bnoordhuis.nl> Cr-Commit-Position: refs/heads/master@{#47778}
-
- 01 Sep, 2017 22 commits
-
-
Jakob Kummerow authored
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I1be2bb5eab7bb869155c526897f32d2c26891aa1 Reviewed-on: https://chromium-review.googlesource.com/646850 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47777}
-
Jakob Gruber authored
Prior to this, AllocateJSArray would go ahead and allocate an empty FixedArray as elements if passed any capacity that is not a compile-time constant 0. Things break later on since we rely on the fact that empty fixed arrays are always canonicalize, and we use obj.elements == empty_fixed_array_constant interchangeably with obj.elements.length == 0. This CL introduces two new branches in AllocateJSArray: one if the capacity is known to be non-zero; and another that explicitly distinguishes between 0 and non-zero capacities. Bug: chromium:760790 Change-Id: I7c22b19ce9ce15a46f91b0f75e6b4a1ff3a29a0f Reviewed-on: https://chromium-review.googlesource.com/645959 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47776}
-
Jakob Kummerow authored
This reverts commit fbe184a6. Reason for revert: Baseline performance test score established, re-enabling feature. Original change's description: > [modules] Temporarily disable IC support for namespace accesses > > To get a proper performance baseline after fixing the perf tests in > https://chromium-review.googlesource.com/c/v8/v8/+/639396. > > This is intended to be reverted after a couple of hours. > > Change-Id: If36e4bfa5bd113599652f5c2016f886533af2746 > Reviewed-on: https://chromium-review.googlesource.com/639057 > Reviewed-by: Adam Klein <adamk@chromium.org> > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47753} TBR=adamk@chromium.org,jkummerow@chromium.org Change-Id: Ia92e3247bc594e2fa6c937d379fa172244df2d8a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/647966Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47775}
-
Clemens Hammacher authored
This violates the style guide, and causes problems for jumbo builds. R=ahaas@chromium.org CC=mostynb@opera.com Bug: chromium:746958 Change-Id: Ic583c41b94bfd9ecdb31a9ccadb2e842861fe7f4 Reviewed-on: https://chromium-review.googlesource.com/647710Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47774}
-
Clemens Hammacher authored
This required splitting wasm-run-utils.h in header and implementation, since the anonymous namespace in wasm-run-utils.h is now gone. This is a reasonable refactoring in itself. R=titzer@chromium.org CC=mstarzinger@chromium.org, mostynb@opera.com Bug: chromium:746958 Change-Id: I0f3b30fef1865cd88eca37b69d0c3a9eb19e77ea Reviewed-on: https://chromium-review.googlesource.com/647587Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47773}
-
Maya Lekova authored
This is a reland of a9f517e2 Original change's description: > [builtins] Port Proxy set trap to CSA > > Bug: v8:6560, v8:6557 > Change-Id: I329794607e8de324fc696652555aaaeafcf519ec > Reviewed-on: https://chromium-review.googlesource.com/625940 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Maya Lekova <mslekova@google.com> > Cr-Commit-Position: refs/heads/master@{#47760} Bug: v8:6560, v8:6557 Change-Id: I1b32992eac6cc5583a44703eed901e4ad15f1947 Reviewed-on: https://chromium-review.googlesource.com/647447 Commit-Queue: Maya Lekova <mslekova@google.com> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#47772}
-
Benedikt Meurer authored
In the BytecodeGraphBuilder we insert a SOFT deopt whenever we see an IC whose state is UNINITIALIZED, i.e. a LOAD_IC or a STORE_IC. This greatly reduces the size of the generated graphs (and also helps to improve generated code quality). However for COMPARE_IC and BINARY_OP_IC we used to stick in the generic JavaScript node instead, which does generate code and might block optimizations because its sitting in the effect chain. This is changed now to always SOFT deopt for UNINITIALIZED instead, consistently with the other ICs. Bug: v8:6760 Change-Id: I2ac7469fa86512a2fd909fdde2c6425977694811 Reviewed-on: https://chromium-review.googlesource.com/645858 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47771}
-
Albert Mingkun Yang authored
Saving/restoring only registers in the restricted set before calling RecordWrite code stub, which prepares for turning on `v8_enable_csa_write_barrier` on all architectures. Bug: chromium:749486 Change-Id: I6c8ba0c1561513569218e80011673cf24c7d6127 Reviewed-on: https://chromium-review.googlesource.com/641531Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com> Cr-Commit-Position: refs/heads/master@{#47770}
-
Clemens Hammacher authored
For stack sizes and control depths, we were sometimes using uint32_t and sometimes size_t. This CL switches to uint32_t consistently. R=titzer@chromium.org Change-Id: I5ce3d63832bc926584b153cf248006cd78d77b97 Reviewed-on: https://chromium-review.googlesource.com/645861Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47769}
-
Benedikt Meurer authored
This CL adds support to optimize for..in in fast enum-cache mode to the same degree that it was optimized in Crankshaft, without adding the same deoptimization loop that Crankshaft had with missing enum cache indices. That means code like for (var k in o) { var v = o[k]; // ... } and code like for (var k in o) { if (Object.prototype.hasOwnProperty.call(o, k)) { var v = o[k]; // ... } } which follows the https://eslint.org/docs/rules/guard-for-in linter rule, can now utilize the enum cache indices if o has only fast properties on the receiver, which speeds up the access o[k] significantly and reduces the pollution of the global megamorphic stub cache. For example the micro-benchmark in the tracking bug v8:6702 now runs faster than ever before: forIn: 1516 ms. forInHasOwnProperty: 1674 ms. forInHasOwnPropertySafe: 1595 ms. forInSum: 2051 ms. forInSumSafe: 2215 ms. Compared to numbers from V8 5.8 which is the last version running with Crankshaft forIn: 1641 ms. forInHasOwnProperty: 1719 ms. forInHasOwnPropertySafe: 1802 ms. forInSum: 2226 ms. forInSumSafe: 2409 ms. and V8 6.0 which is the current stable version with TurboFan: forIn: 1713 ms. forInHasOwnProperty: 5417 ms. forInHasOwnPropertySafe: 5324 ms. forInSum: 7556 ms. forInSumSafe: 11067 ms. It also improves the throughput on the string-fasta benchmark by around 7-10%, and there seems to be a ~5% improvement on the Speedometer/React benchmark locally. For this to work, the ForInPrepare bytecode was split into ForInEnumerate and ForInPrepare, which is very similar to how it was handled in Fullcodegen initially. In TurboFan we introduce a new operator LoadFieldByIndex that does the dynamic property load. This also removes the CheckMapValue operator again in favor of just using LoadField, ReferenceEqual and CheckIf, which work automatically with the EscapeAnalysis and the BranchConditionElimination. Bug: v8:6702 Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a Reviewed-on: https://chromium-review.googlesource.com/645949 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#47768}
-
Ben L. Titzer authored
This CL moves most of the logic of capturing simple stack frames from the mentioned method into a FrameArrayBuilder class. This further encapsulates that logic and makes it easier to refactor this code to use a callback interface for walking the stack. Bug: Change-Id: Ib0b31d9eb8c4031aa64f393982889d0d02b56639 Reviewed-on: https://chromium-review.googlesource.com/645957 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47767}
-
Michael Lippautz authored
Bug: Change-Id: Ic14afce939f0c65cddbbb917538b3d7cd443546e Reviewed-on: https://chromium-review.googlesource.com/646022Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47766}
-
Clemens Hammacher authored
After the FallThruTo in kExprEnd, the current block {c} is never unreachable. Hence, the check for {c->unreachable} afterwards can be removed. In the loop case, the {TypeCheckFallThru} already adds entries for non-existing values to the stack, so no need to {PushEndValues}. Also, add more tests for the loop case. R=titzer@chromium.org Change-Id: I8737affaeed2ea663bd6ddafa36532ca9a7379bb Reviewed-on: https://chromium-review.googlesource.com/645859Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47765}
-
Benedikt Meurer authored
This reverts commit a9f517e2. Reason for revert: Makes array sort flaky? https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug/builds/17894/steps/OptimizeForSize%20%28flakes%29/logs/array-sort Original change's description: > [builtins] Port Proxy set trap to CSA > > Bug: v8:6560, v8:6557 > Change-Id: I329794607e8de324fc696652555aaaeafcf519ec > Reviewed-on: https://chromium-review.googlesource.com/625940 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Maya Lekova <mslekova@google.com> > Cr-Commit-Position: refs/heads/master@{#47760} TBR=neis@chromium.org,franzih@chromium.org,ishell@chromium.org,bmeurer@chromium.org,mslekova@google.com Change-Id: Ibebf5e694945e59bd2808841108e6686af51efaf No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6560, v8:6557 Reviewed-on: https://chromium-review.googlesource.com/646169Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47764}
-
Jaroslav Sevcik authored
This helps with patterns such as ((a[i] + n) + m) | 0 where we know n and m are small integers, and a[i] is a holey smi array where we have never read a hole so far. In that case, we still perform the additions with overflow checks since we currently only propagate/use the truncation if the operation outcome is in the safe-integer range (without taking feedback into account). The problem here is that both 'n + a[i]' and '(n + a[i]) + m' have type Union(Range(..., ...), NaN), even though the NaN will never pass the Smi check on a[i]. This CL changes restricts the static type of SpeculativeSafeInteger(Add|Subtract) to the safe integer range. This is safe because we will always either truncate or use the feedback (i.e., deopt if the inputs are not Signed32). In either case, the result will always be in safe-integer range. As a result, we will perform the second addition without overflow check. Getting rid of the overflow check on the first is done in a separate CL. Bug: v8:5267,v8:6764 Change-Id: I27dba0fda832fc1f04477db6dd3495d5b4b2bd0b Reviewed-on: https://chromium-review.googlesource.com/634903 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47763}
-
Jaroslav Sevcik authored
Bug: v8:5267 Change-Id: Iea44ba7ee6ba09580176936e6157d63c53d06446 Reviewed-on: https://chromium-review.googlesource.com/646021 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47762}
-
Michael Starzinger authored
This adds support for lowering {JSCreateArguments} within outermost frames of type {CreateArgumentsType::kMappedArguments}. It will hence enable escape analysis to work with such objects and allow for further optimization. This also adds a new {NewMappedArgumentsElements} simplfied operator. Note that escape analysis support for this new operator will be done as a follow-up. R=tebbi@chromium.org Change-Id: I0e2fac25c654f796433f57b116964053b6b68635 Reviewed-on: https://chromium-review.googlesource.com/641454 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#47761}
-
Maya Lekova authored
Bug: v8:6560, v8:6557 Change-Id: I329794607e8de324fc696652555aaaeafcf519ec Reviewed-on: https://chromium-review.googlesource.com/625940Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Maya Lekova <mslekova@google.com> Cr-Commit-Position: refs/heads/master@{#47760}
-
Michael Lippautz authored
Bug: Change-Id: Icfd75c2b0f7d127ae5902e9e0f9bdfd8b9b127e5 Reviewed-on: https://chromium-review.googlesource.com/645989Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47759}
-
Michael Starzinger authored
R=jkummerow@chromium.org Change-Id: I8937933e9ec5b4bd150f5a044700716db458f365 Reviewed-on: https://chromium-review.googlesource.com/645691Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47758}
-
jgruber authored
This adds an initial implementation of the DeserializeLazy builtin and runtime function, as well as --lazy-deserialization and --trace-lazy-deserialization feature flags. Since lazy deserialization itself isn't implemented yet, DeserializeLazy simply replaces itself with the appropriate builtin. The builtin_id is loaded from the SFI, and the builtin itself is loaded from the Builtins table. Bug: v8:6624 Change-Id: I4ef8c3030a8cda19a086b8e569a24d97213b5ed8 Reviewed-on: https://chromium-review.googlesource.com/643289Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47757}
-
Franziska Hinkelmann authored
Bug: v8:6704 Change-Id: I77388b91061f934943a707a645080dfdcf481836 Reviewed-on: https://chromium-review.googlesource.com/645951Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Franziska Hinkelmann <franzih@chromium.org> Cr-Commit-Position: refs/heads/master@{#47756}
-