- 04 Sep, 2019 1 commit
-
-
Georg Neis authored
This is a reland of ab089c78, after making a flaky test more robust. Original change's description: > [turbofan] Prepare for moving part of CreateGraph into the background > > - Pass Refs, not Handles, to graph builder, and drop bytecode array argument > (get it from SFI instead). > - Add some fields to FeedbackVectorRef that are needed to avoid heap access > in BytecodeGraphBuilderPhase. > - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more > than just the feedback slots. > - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such > that CreateGraph is last. > > Bug: v8:7790 > Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63515} Bug: v8:7790 Change-Id: Ia6f4c1ebd82dea93c14437514d0e25b730523f75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781694Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63545}
-
- 03 Sep, 2019 2 commits
-
-
Leszek Swirski authored
This reverts commit ab089c78. Reason for revert: Breaking GC stress (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/27523) Original change's description: > [turbofan] Prepare for moving part of CreateGraph into the background > > - Pass Refs, not Handles, to graph builder, and drop bytecode array argument > (get it from SFI instead). > - Add some fields to FeedbackVectorRef that are needed to avoid heap access > in BytecodeGraphBuilderPhase. > - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more > than just the feedback slots. > - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such > that CreateGraph is last. > > Bug: v8:7790 > Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682 > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63515} TBR=neis@chromium.org,mslekova@chromium.org Change-Id: I4dc95907657597d12cbe1ce6a8ebb694ef44e915 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781687Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#63517}
-
Georg Neis authored
- Pass Refs, not Handles, to graph builder, and drop bytecode array argument (get it from SFI instead). - Add some fields to FeedbackVectorRef that are needed to avoid heap access in BytecodeGraphBuilderPhase. - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more than just the feedback slots. - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such that CreateGraph is last. Bug: v8:7790 Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682Reviewed-by: Maya Lekova <mslekova@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63515}
-
- 30 Aug, 2019 1 commit
-
-
Maya Lekova authored
Introduce JSGlobalObjectRef to the heap broker. Bug: v8:7790 Change-Id: I055a0545b582d6ff4c4e0dd639ce532311a76fec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773267Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#63472}
-
- 17 Jul, 2019 1 commit
-
-
Tobias Tebbi authored
This adds a simple counter to Turbofan that's incremented throughout the compilation, hopefully frequently enough so we can use it to detect divergence and performance bugs. In addition, we assert that this counter never gets too high. That's the equivalent of a simple timeout, just more deterministic. The limitations on Turbofan input size should guarantee that we never exceed this limit. Since we probably do exceed it rarely, this check is only a DCHECK and intended to detect performance and divergence issues, but not supposed to be performed in release builds. In addition, this CL adds UMA stats to observe the real world distribution of the tick measurement. Bug: v8:9444 Change-Id: I182dac6ecac64715e3f5885ff5c7c17549351cd0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1695475 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62754}
-
- 15 Jul, 2019 1 commit
-
-
Georg Neis authored
When --concurrent-inlining is on, run bytecode analysis for all relevant functions at serialization time, and store the results in the broker. Change bytecode analysis such that running it for OSR produces information that subsumes the non-OSR case. This lets us avoid doing and storing two analyses for the top-level function in case we do OSR and the function gets inlined into itself. Bug: v8:7790 Change-Id: I7d5df0b2652e6e5c758c85578e51b4f8d041b0d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1690959 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#62711}
-
- 08 Jul, 2019 1 commit
-
-
Georg Neis authored
Change-Id: I9285052dfe21df8e0eaf0e0493458532f82504ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687421Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62546}
-
- 23 May, 2019 2 commits
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
Yang Guo authored
Bug: v8:9247 Change-Id: I0023200c54fa6499ae4e2cf5e4c89407cc35f187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624218Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61762}
-
- 14 May, 2019 1 commit
-
-
Georg Neis authored
This work-around got lost in the recent refactorings. Bug: v8:8193 Change-Id: I81d22e0702666d1d8ef954cd3d074e22c89378cd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1609806 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#61468}
-
- 06 May, 2019 1 commit
-
-
Jaroslav Sevcik authored
Bug: v8:7790 Change-Id: I513c3ba048eafb7ca5bfa2fb63e35143f49643ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1596736 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61246}
-
- 29 Apr, 2019 3 commits
-
-
Georg Neis authored
Also const-ify and refactor a few things in BytecodeAnalysis. Change-Id: Ibd261bb67d8c035b1f818e9114d09db08737000d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587384 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#61088}
-
Georg Neis authored
- Rename (and negate) "stack_check" to the more descriptive "skip_first_stack_check". - Pass call frequency by value rather than mutable(!) reference. - Embed some things directly into BytecodeGraphBuilder, instead of stack-allocating them and then storing a pointer. - Don't pass things to OsrIteratorState that it can already access via the graph builder parameter. Change-Id: Id852df1ce521a6eefb6047cf76a0882a4c6e95b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587375 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61072}
-
Georg Neis authored
All we really need to expose is a single function that builds the graph. This change drastically simplifies the header file. Change-Id: If185687b8220bdd253f967be9ab2ea3b088e5423 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585856Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#61068}
-
- 25 Feb, 2019 1 commit
-
-
Ross McIlroy authored
Template objects should be cached after they are first created and reused on subsiquent calls to tag functions. Currently these cached objects are stored on the feedback vector, which has appropriate lifetime, however with bytecode flushing the feedback vector could be cleared when the bytecode is flushed, causing the template object to be dropped. In order to retain the cached template objects in the face of bytecode flushing, this CL adds a weakmap for each native context that is (weakly) keyed by shared function info, and holds a linked list of cached template objects associated with that shared function info, indexed by feedback vector slot id. Misses will check this weakmap, and if no entry is found, a new template object is created and added into this weakmap alongside the feedback vector. BUG=v8:8799,v8:8799,v8:8395 Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17 Reviewed-on: https://chromium-review.googlesource.com/c/1477746 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59818}
-
- 15 Nov, 2018 1 commit
-
-
Ross McIlroy authored
With Bytecode flushing, the a SharedFunctionInfo's bytecode might be flushed while the compiler is expecting it to still exist. Rather than continually getting the bytecode from the SFI, instead bottleneck the points where we get BytecodeArray from SFIs and maintain an explicit strong reference to the BytecodeArray from that point onwards to prevent flushing. BUG=v8:8395 Change-Id: I6a18adec99402838690971eb37ee0617cdc15920 Reviewed-on: https://chromium-review.googlesource.com/c/1309763 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#57536}
-
- 27 Sep, 2018 1 commit
-
-
Vasili Skurydzin authored
Bug: v8:8193 GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61976 Change-Id: I0d4efca4da03ef82651325e15ddf2160022bc8de Reviewed-on: https://chromium-review.googlesource.com/1228633Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Junliang Yan <jyan@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#56275}
-
- 09 Aug, 2018 1 commit
-
-
jgruber authored
The HasProperty builtin differed in its expected argument order from the HasProperty runtime function. Like all other related spec primitives (e.g.: GetProperty, SetProperty, DeleteProperty), it should take {object} as the first argument and {key} as the second. This CL changes the builtin and all related spots to use the correct order. There was also a tricky bug in interpreter intrinsic rewriting, which assumes (but does not verify) that the argument order between runtime function and builtin is identical. Besides cctests, HasProperty intrinsic rewriting seems to be dead code. Bug: v8:8036 Change-Id: Ia669fd6f5c73a30df4e4607064603be759ced392 Reviewed-on: https://chromium-review.googlesource.com/1167297 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#55022}
-
- 20 Jul, 2018 1 commit
-
-
Caitlin Potter authored
As discussed in https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#, this CL introduces a new bytecode (CloneObject), and a new IC type. In this prototype implementation, the type feedback looks like the following: Uninitialized case: { uninitialized_sentinel, uninitialized_sentinel } Monomorphic case: { weak 'source' map, strong 'result' map } Polymorphic case: { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value } Megamorphic case: { megamorphic_sentinel, cleared_Value } In the fast case, Object cloning is done by allocating an object with the saved result map, and a shallow clone of the fast properties from the source object, as well as cloned fast elements from the source object. If at any point the fast case can't be taken, the IC transitions to the slow case and remains there. This prototype CL does not include any TurboFan optimization, and the CloneObject operation is merely reduced to a stub call. It may still be possible to get some further improvements by somehow incorporating compile-time boilerplate elements into the cloned object, or simplifying how the boilerplate elements are inserted into the object. In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/ by about 8x, with substantial improvements over the Babel and ObjectAssign scores. R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org BUG=v8:7611 Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e Reviewed-on: https://chromium-review.googlesource.com/1127472 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#54595}
-
- 15 Jun, 2018 1 commit
-
-
Leszek Swirski authored
Bug: v8:7786 Change-Id: I1e568ff6da02dfd92b24b8badd665096cf49a13a Reviewed-on: https://chromium-review.googlesource.com/1101321Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#53747}
-
- 29 Mar, 2018 1 commit
-
-
Benedikt Meurer authored
This way we can teach the debugger to disable liveness analysis when running with (potential) breakpoints, so that the developers always have (read) access to all scoped variable values. Bug: v8:7608, chromium:826613 Change-Id: I7e6cea105f111c99d2620546144201624dfe1d8b Reviewed-on: https://chromium-review.googlesource.com/985838Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52293}
-
- 27 Feb, 2018 1 commit
-
-
Michael Starzinger authored
This changes the encoding of the {HandlerTable} from an array of Smi values to a byte array. It allows embedding of said array into the instruction stream of {Code} objects (similar to how safepoint tables work). For interpreted bytecode the table is attached as a {ByteArray} to the bytecode. The advantage of this approach is a more compact encoding and also the ability to move such tables easily off the GC'ed heap if needed (as is done for WebAssembly code for example). R=jarin@chromium.org Change-Id: I3320415dff69b3d1053825bda0d667a28232bf6d Reviewed-on: https://chromium-review.googlesource.com/934642 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51589}
-
- 01 Feb, 2018 1 commit
-
-
Tobias Tebbi authored
Change-Id: I2e9a6e706d75a579033a3bdaf275a5af4512c8d1 Reviewed-on: https://chromium-review.googlesource.com/897492Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#51026}
-
- 24 Jan, 2018 1 commit
-
-
Tobias Tebbi authored
Bug: Change-Id: Ia5df528e7e2129a4c6e029b75279015836147c95 Reviewed-on: https://chromium-review.googlesource.com/881145 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50824}
-
- 23 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Currently, yields and awaits inside loops compile to bytecode which switches to the top of the loop header, and switch again once inside the loop. This is to make loops reducible. This replaces this switching logic with a single switch bytecode that directly jumps to the bytecode being resumed. Among other things, this allows us to no longer maintain the generator state after the switch at the top of the function, and avoid having to track loop suspend counts. TurboFan still needs to have reducible loops, so we now insert loop header switches during bytecode graph building, for suspends that are discovered to be inside loops during bytecode analysis. We do, however, do some environment magic across loop headers since we know that we will continue switching if and only if we reached that loop header via a generator resume. This allows us to generate fewer phis and tighten liveness. Change-Id: Id2720ce1d6955be9a48178322cc209b3a4b8d385 Reviewed-on: https://chromium-review.googlesource.com/866734 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50804}
-
- 22 Jan, 2018 1 commit
-
-
Leszek Swirski authored
Instead of requiring the pattern that a SuspendGenerator must be followed by a Return, make SuspendGenerator return directly. This can, in the future, simplify some of the reasoning around generator suspends. Change-Id: I94c0156a89dc0e1c0bc306bc57acf766f3b4deb5 Reviewed-on: https://chromium-review.googlesource.com/857463Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#50748}
-
- 14 Dec, 2017 1 commit
-
-
Igor Sheludko authored
Given that we already treat feedback vector as a source of truth for language mode of other store operations and given that the StoreGlobalIC dispatcher does not depend on the language more anymore, we can just combine these two bytecodes. Bug: v8:7206 Change-Id: I27f03f2102ff79ec20fa997eb18dde816f376b00 Reviewed-on: https://chromium-review.googlesource.com/823846Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#50102}
-
- 11 Dec, 2017 1 commit
-
-
Sigurd Schneider authored
TBR=neis@chromium.org Bug: v8:7127 Change-Id: Ic7c98f0f03d57fc748badddb921430818ec2f790 Reviewed-on: https://chromium-review.googlesource.com/819351 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50002}
-
- 08 Dec, 2017 1 commit
-
-
Sigurd Schneider authored
This patch adds a field for the speculation mode to Call nodes, and passes the speculation mode from the CallIC to the Call node in the byte code graph builder. Bug: v8:7127 Change-Id: I89fa10643b46143b36776de1d5ba6ebe3fa2c878 Reviewed-on: https://chromium-review.googlesource.com/814537 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49965}
-
- 07 Dec, 2017 1 commit
-
-
Sigurd Schneider authored
This is a preparation for a larger CL that needs VectorSlotPair throughtout the compilation chain (including deoptimizer.cc). Bug: v8:7127 Change-Id: Ia746805ca3fa294eedba19d23656f858840cd501 Reviewed-on: https://chromium-review.googlesource.com/813934Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#49928}
-
- 28 Nov, 2017 1 commit
-
-
Georg Neis authored
... in the same style as the previous CLs for negation and bitwise-not. R=jarin@chromium.org Bug: v8:6791 Change-Id: I0aa96a72421e90c8c82a39dd4264fdcf00967504 Reviewed-on: https://chromium-review.googlesource.com/779141 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49658}
-
- 21 Nov, 2017 1 commit
-
-
Georg Neis authored
This introduces a JSNegate operator and lowers it either to a speculative multiplication with -1 (when we have Number feedback) or to a stub call. The stub is also new. R=jarin@chromium.org Bug: v8:6791 Change-Id: I8e20333fe49cc6088d2d10777be982e42eed2412 Reviewed-on: https://chromium-review.googlesource.com/774718 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49538}
-
- 22 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
Tagged templates were previously desugared during parsing using some combination of runtime support written in JavaScript and C++, which prevented some optimizations from happening, namely the constant folding of the template object in TurboFan optimized code. This CL adds a new bytecode GetTemplateObject (with a corresponding GetTemplateObject AST node), which represents the abstract operation in the ES6 specification and allows TurboFan to simply constant-fold template objects at compile time (which is explicitly supported by the specification). This also pays down some technical debt by removing the template.js runtime support and therefore should reduce the size of the native context (snapshot) a bit. With this change in-place the ES6 version microbenchmark in the referenced tracking bug is now faster than the transpiled Babel code, it goes from templateStringTagES5: 4552 ms. templateStringTagES6: 14185 ms. templateStringTagBabel: 7626 ms. to templateStringTagES5: 4515 ms. templateStringTagES6: 7491 ms. templateStringTagBabel: 7639 ms. which corresponds to a solid 45% reduction in execution time. With some further optimizations the ES6 version should be able to outperform the ES5 version. This micro-benchmark should be fairly representative of the six-speed-templatestringtag-es6 benchmark, and as such that benchmark should also improve by around 50%. Bug: v8:6819,v8:6820 Tbr: mlippautz@chromium.org Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48126}
-
- 14 Sep, 2017 1 commit
-
-
Jaroslav Sevcik authored
This reverts commit 14b424c3. Reason for revert: Regresses benchmarks, e.g., Octane/gameboy Original change's description: > [turbofan] Lower monomorphic loads during graph building. > > We introduce an explicit LoweringResult data structure. Until this change, > the lowering result could be recovered from the node. However, lowering > monomorphic loads requires wiring different value and effect, so we need > a structure that can express such lowering result. > > Bug: v8:6357 > Change-Id: I92655800890b744d9203a778a1936a8dcd465ed3 > Reviewed-on: https://chromium-review.googlesource.com/637304 > Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47992} TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org Change-Id: I2b7db0278c13414e20c94a34d215ed92bd0d412b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6357 Reviewed-on: https://chromium-review.googlesource.com/667016Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48012}
-
- 13 Sep, 2017 1 commit
-
-
Jaroslav Sevcik authored
We introduce an explicit LoweringResult data structure. Until this change, the lowering result could be recovered from the node. However, lowering monomorphic loads requires wiring different value and effect, so we need a structure that can express such lowering result. Bug: v8:6357 Change-Id: I92655800890b744d9203a778a1936a8dcd465ed3 Reviewed-on: https://chromium-review.googlesource.com/637304 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47992}
-
- 12 Sep, 2017 1 commit
-
-
Adam Klein authored
This continues to move the "desugaring" of unary operators further down the pipeline, in this case into the bytecode handlers for new bytecodes `Negate` and `BitwiseNot` and the corresponding TF code in BytecodeGraphBuilder. Bug: v8:6971 Tbr: yangguo@chromium.org Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb Reviewed-on: https://chromium-review.googlesource.com/661146 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47980}
-
- 07 Sep, 2017 1 commit
-
-
Ross McIlroy authored
JS runtime calls are always created with undefined recievers, so make the bytecode behave similarly to CallUndefinedReciever such that we don't need to push an explicit undefined register for the receiver for such calls. Modifies the Async[Generator/Function]Await[Caught/Uncaught] runtime calls to pass the generator in the first argument rather than the reciever since these runtime calls were desugered in the bytecode generator and explicitly passed the generator in the receiver. Change-Id: I36c8087bb3b663dccd805bfdb1eea04eb6a73269 Reviewed-on: https://chromium-review.googlesource.com/654257Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47870}
-
- 05 Sep, 2017 1 commit
-
-
Jakob Kummerow authored
Only the error cases of overwriting readonly properties need the language_mode to decide whether to throw or be silent. Reading it from the feedback vector's metadata (just like the C++ code in ic.cc does) removes the need to duplicate each stub for each language_mode ("StoreIC" + "StoreICStrict" etc.). Change-Id: Ic0c67f9d40ca36c65e41b4f162b2ab70d155e549 Reviewed-on: https://chromium-review.googlesource.com/647373Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47836}
-
- 01 Sep, 2017 2 commits
-
-
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}
-
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}
-