- 16 Oct, 2019 15 commits
-
-
Jakob Kummerow authored
for "entries", i.e. indices into the backing store (as opposed to "public indices" going into the hash function). This improves consistency and compiler-enforced type safety; no change in behavior is intended. Change-Id: I25e57e3ddcf18a406e2dfbd66786b6980c4e9615 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852768 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64317}
-
Sathya Gunasekaran authored
This reverts commit c7c47c68. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
-
Mu Tao authored
Port a8cdda99 Original Commit Message: WebAssembly locals are specified to be zero on function entry. Liftoff implements this by just storing the constant 0 in the virtual stack for integer types, and using one floating point register initialized to zero for all floating point types. For big counts of locals this leads to problems (manifesting as huge blocks of code being generated) once we hit a merge point: All those constants (for int) and all duplicate register uses (for floats) need to be fixed up, by using separate registers for the locals or spilling to the stack if no more registers are available. All this spilling generates a lot of code, and can even happen multiple times within a function. This CL optimizes for such cases by spilling all locals to the stack initially. All merges within the function body get much smaller then. The spilled values rarely have to be loaded anyway, because the initial zero value is usually overwritten before the first use. To optimize the code size for initializing big numbers of locals on the stack, this CL also introduces the platform-specific {FillStackSlotsWithZero} method which uses a loop for bigger local counts. This often saves dozens of kilobytes for very big functions, and shows an overall code size reduction of 4-5 percent for big modules. R=xwafish@gmail.com Change-Id: Id65b6d36beadcba0d3f3726bb6559bb316cb212e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862830 Auto-Submit: Mu Tao <pamilty@gmail.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Mu Tao <pamilty@gmail.com> Cr-Commit-Position: refs/heads/master@{#64315}
-
Toon Verwaest authored
This is a reland of f05bae1e Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64314}
-
Matheus Marchini authored
Symbol and *String classes are now declared on Torque with generateCppClass, which means they don't use macro accessors anymore. As such, the gen-postmortem-metadata script is not able to automatically detect fields for those classes. Define metadata for those fields manually for now. In the future we might want to generate it from Torque for consistency. Also renamed a few *String fields metadata to match the expected format (className__fieldName__fieldType). For more context: https://github.com/nodejs/llnode/issues/287#issuecomment-539707117. R=bmeurer@chromium.org, hpayer@chromium.org, verwaest@chromium.org, yangguo@chromium.org Change-Id: I82fe8315cdbfd1b8c64c6a8d5dc011b1edaec39e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847783Reviewed-by:
-
Thibaud Michaud authored
This prevents the branch table iterator's has_next() method to trigger a DCHECK when the decoder fails before the end of table decoding. R=clemensb@chromium.org Change-Id: I2258886501b77cd4c8fe98bc8a4ed0b66fb23066 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864931Reviewed-by:
-
Liviu Rau authored
Using test runner with option --progress=ci can generate output timeouts in an actual CI environment. To avoid that we gonna write a timestamp in the standard output at every minute. Bug: v8:9146 Change-Id: Id2f05530956b01d9b07809e509cd0cefc0be54b2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863196 Commit-Queue: Liviu Rau <liviurau@chromium.org> Reviewed-by:
Tamer Tas <tmrts@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#64311}
-
Clemens Backes authored
DCHECKs are not really special, they just create a non-constexpr path within an otherwise constexpr function. Since C++14, this is allowed. Unfortunately, gcc only supports this since version 6, but we still need to support gcc 5. R=ulan@chromium.org Change-Id: If74486144abafa5bbdcdbb9a567ee9295ac4cfc7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862568Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64310}
-
Thibaud Michaud authored
R=ahaas@chromium.org Change-Id: I0405abbd8fc047653758ac41d185bf0f44e33d09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859617 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#64309}
-
Michael Starzinger authored
R=clemensb@chromium.org BUG=v8:6847,chromium:893069 Change-Id: I5b5ada546e1d0b9d42ea8f7278671bf2b128bef8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862570Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Sigurd Schneider authored
This fixes a bug where coverage for the inline script <script>function foo() {}<script> started to get deterministically reported as covered after crrev.com/c/1771776, while before it, we most of the time reported it as uncovered (depending on heap order of SFIs). The correct result is to report `foo` as uncovered as it is never called. The problem arose from the fact that v8:9212 needed to handle extra-wrappers around scripts correctly. Those wrappers have the same source range as the wrapped script and a call count of zero even if the wrapped script is executed. To filter them out, we previously determined nesting for identical source ranges by ascending call count. However, in the script case above, the script has call count one, while `foo` (which has the same source range) has call count zero. In this case, nesting is decreasing order of call counts. This CL is a minimal change that sorts SFIs which are top-level to the front, only then considers call counts in descending order. This preserves the behavior that node's extra wrappers are sorted to the front (and then filtered out by existing logic), but also ensures that for the example above, we report the script's coverage before the coverage for `foo`. Bug: v8:9857, v9:9212 Change-Id: Id224b0d8f12028b1f586ee5039e126bb5b8d8d36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863197Reviewed-by: -
Jakob Gruber authored
Named capture properties on the groups object should be ordered by the capture index (and not alpha-sorted). This was accidentally broken in https://crrev.com/c/1687413. Bug: v8:9822,v8:9423 Change-Id: Iac6f866f077a1b7ce557ba47e8ba5d7e7014b3ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864829 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Simon Zünd authored
This is a reland of 1c56974f This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/c1d5d48..082f11b Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/0b36537..b9fad2f Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/c651221..ba97f60 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/6bc727d..c5d85f1 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Icd2741e2b01d6b49153dcee23c63883f8bf78193 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863442Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#64304}
-
Z Nguyen-Huu authored
Bug: v8:8976 Change-Id: I992b5527fc1d8f58b2fdb5a212651a933c25f856 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860998 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
-
- 15 Oct, 2019 21 commits
-
-
Deepti Gandluri authored
Bug: v8:9854 Change-Id: Icb41622caa4a7e0a7262048f69b40cfbe8fa17bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860406Reviewed-by:
Zhi An Ng <zhin@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#64302}
-
Milad Farazmand authored
Port a8cdda99 Original Commit Message: WebAssembly locals are specified to be zero on function entry. Liftoff implements this by just storing the constant 0 in the virtual stack for integer types, and using one floating point register initialized to zero for all floating point types. For big counts of locals this leads to problems (manifesting as huge blocks of code being generated) once we hit a merge point: All those constants (for int) and all duplicate register uses (for floats) need to be fixed up, by using separate registers for the locals or spilling to the stack if no more registers are available. All this spilling generates a lot of code, and can even happen multiple times within a function. This CL optimizes for such cases by spilling all locals to the stack initially. All merges within the function body get much smaller then. The spilled values rarely have to be loaded anyway, because the initial zero value is usually overwritten before the first use. To optimize the code size for initializing big numbers of locals on the stack, this CL also introduces the platform-specific {FillStackSlotsWithZero} method which uses a loop for bigger local counts. This often saves dozens of kilobytes for very big functions, and shows an overall code size reduction of 4-5 percent for big modules. R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: I2459080a1f6acfdd212e9a93a868d028980c5554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863370Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Reviewed-by:
Milad Farazmand <miladfar@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#64301}
-
Adam Klein authored
Previous API owners (adamk, yangguo) are less-involved with the JS API then ever, so it seems appropriate to have an owner whose responsibility is squarely in the JS domain. Change-Id: I4235778fda8f55d0429e875d52ff74049024dad1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860328Reviewed-by:
-
Sathya Gunasekaran authored
This reverts commit f05bae1e. Reason for revert: broke arm sim debug https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/17714 https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8899519852984476944/+/steps/Check_-_trusted/0/logs/FunctionDetailsInlining/0 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: Ie7b4086c3a9ab2627ecac599da36b20cf8d1f948 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863200Reviewed-by:
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: I9dab61c4260436d08171ac0ff084e05d75c5c5e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862573Reviewed-by:
-
Dan Elphick authored
Add overrides to port specific assemblers and delete redundant empty override. Bug: v8:9810 Change-Id: I17e4614e06783867ae50e87bba83d35ebc9d0b51 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862567 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
-
Toon Verwaest authored
Remove the native context slot from contexts by making context maps native-context-specific. Now we require 2 loads to go from a context to the native context, but we have 1 field fewer to store when creating contexts. Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
-
Michael Achenbach authored
Change-Id: I3520bce4cc3ac2db55891b1ebe52782566d98f90 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863189Reviewed-by:
-
Seth Brenith authored
The tests were already passing because they happened to use objects allocated in the lower half of the heap reservation, but this small change should make behavior more consistent. Change-Id: Ib6be3123d347234f4771c213f2209bfe6e19c569 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860332Reviewed-by:
-
Clemens Backes authored
This reverts commit 1c56974f. Reason for revert: Causes several bots to timeout, e.g. https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20debug/27945 Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Change-Id: I4024d818877e534b9f7908a2d14f33dca35b5924 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:8531 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862572Reviewed-by:
-
Clemens Backes authored
We currently generate code for both separately, resulting in five instructions (three for the i32_eqz, two for the br_if): test rax,rax seteq dl movzxb rdx,rdx test rdx,rdx jz <label> After this CL, we just generate two instructions: test rax, rax jnz <label> This is implemented by a look-ahead in the {kExprI32Eqz} handler. If the opcode is followed by {kExprBrIf}, no code is emitted. Instead, a flag in the {LiftoffCompiler} is set to signal to the {kExprBrIf} handler that the previous instruction was not processed yet. Note that this mechanism is designed to be reusable for more similar improvements. For the single instance implemented in this CL, it is not needed. Plus some drive-by cleanup. R=jkummerow@chromium.org Bug: v8:9831 Change-Id: I47495fe763b7db7cef41aa207c88a2f1b74bf1a9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862557 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#64292}
-
Ulan Degenbaev authored
AsmJs does not support SharedArrayBuffers. This CL adds a check in instantiation and reports a proper error. Bug: chromium:1013920 Change-Id: Id7159f23ddcc2bde139c4c97bdb67ef3dc7f0e22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862563Reviewed-by:
-
Simon Zünd authored
This CL removes 'v8_use_snapshot' and the usages of the implied V8_USE_SNAPSHOT define. One test runner unittest was updated to use the "asan" variant instead of the now obsolete "no_snap" variant. Related chromium CL: https://crrev.com/c/1796325. Bug: v8:8531 Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:
Nico Weber <thakis@chromium.org> Reviewed-by:
-
Igor Sheludko authored
... which broke with 32-bit Smis. Tbr: verwaest@chromium.org No-Tree-Checks: true Bug: v8:9767 Change-Id: I459a5d807d87012ab72138f46b49362f16b6baa1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862562Reviewed-by:
-
Igor Sheludko authored
We are not shipping ptr-compr in M79 on x64 because chromium:1009439 blocks 31-bit Smis on 64-bit architectures, so these's no point in disabling double fields unboxing. This CL will be reverted after the M79 branch point. Bug: v8:9799, chromium:1009439 Change-Id: I28d0013d3ab06ce41d5028ba4f66c9b249de52d7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862556Reviewed-by:
-
Leszek Swirski authored
Fix uses of cached descriptors arrays used in loops that map-check to ensure validity of the cache to also reload the descriptor in case there are missed in-place representation updates. As a drive-by, introduce inner HandleScopes for these loops. Bug: chromium:1012301 Change-Id: I17273caf629a181b846d3c09777b5c08fd8cbb0e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859621Reviewed-by:
-
Igor Sheludko authored
The reason is to unblock M79 blocked by chromium:1009439 while full solution is not ready yet. This CL will be reverted after the M79 branch point. Bug: v8:9767, chromium:1009439 Change-Id: I5302d86fe953ecd94d9a4bba0d29c807b7b9d703 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862554Reviewed-by:
-
Michael Starzinger authored
This replaces all left-over uses of {WasmGraphBuilder::Buffer} with proper alternatives (e.g. using {base::SmallVector} instead). R=clemensb@chromium.org Change-Id: I2607ce7e2638a1bb35daccbb5b38382d5b62a430 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859626Reviewed-by: -
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/4250046..c1d5d48 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/1550399..0b36537 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/5abb9b7..c651221 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ib22d731a92b9e4bec2c4cf22476f3c4e01a2c3a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860559Reviewed-by:
-
Michael Lippautz authored
Use v8::Data as basetype for managed objects that can integrate with v8::EmbedderHeapTracer. Bug: v8:9841 Change-Id: Id3e06701207a23870cea89e1d7d334c48fcd3006 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856002Reviewed-by:
-
Clemens Backes authored
WebAssembly locals are specified to be zero on function entry. Liftoff implements this by just storing the constant 0 in the virtual stack for integer types, and using one floating point register initialized to zero for all floating point types. For big counts of locals this leads to problems (manifesting as huge blocks of code being generated) once we hit a merge point: All those constants (for int) and all duplicate register uses (for floats) need to be fixed up, by using separate registers for the locals or spilling to the stack if no more registers are available. All this spilling generates a lot of code, and can even happen multiple times within a function. This CL optimizes for such cases by spilling all locals to the stack initially. All merges within the function body get much smaller then. The spilled values rarely have to be loaded anyway, because the initial zero value is usually overwritten before the first use. To optimize the code size for initializing big numbers of locals on the stack, this CL also introduces the platform-specific {FillStackSlotsWithZero} method which uses a loop for bigger local counts. This often saves dozens of kilobytes for very big functions, and shows an overall code size reduction of 4-5 percent for big modules. R=jkummerow@chromium.org Bug: v8:9830 Change-Id: I23fa4145847827420f09e043a11e0e7b606e94cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856004 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
- 14 Oct, 2019 4 commits
-
-
Deepti Gandluri authored
Bug: v8:9854 Change-Id: I8450e6456321f3be2badeccac61414e005df2c65 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860327 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
-
Ng Zhi An authored
The macros will use AVX variants when available. Bug: v8:9561 Change-Id: I06872a08184983adc8018ffdf03916feac02016f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1857422Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#64280}
-
Z Nguyen-Huu authored
Bug: v8:8976 Change-Id: I7b215adda82f9982d38e35ab5c80c86eeca81487 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856921 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
-
Ng Zhi An authored
Bug: v8:8460 Change-Id: I2ca4b4aa5d7755f09252bdec6885013c84ea469c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1850612Reviewed-by:
-
