- 27 Nov, 2017 1 commit
-
-
Sathya Gunasekaran authored
Previously, the class fields initializer function was stored on a synthetic context allocated variable. This approach had sevaral problems: - We didn't know that class literal had fields until after we had completely parsed the class literal. This meant that we had to go back and fix up the scope of the constructor to have this synthetic variable. This resulted in mismatch between parser and preparsed scope data. - This synthetic variable could potentially resolve to an initializer of an outer class. For ex: class X extends Object { c = 1; constructor() { var t = () => { class P extends Object { constructor() { var t = () => { super(); }; t(); } } super(); } t(); } } In this the inner class P could access the outer class X's initiliazer function. We would have to maintain extra metadata to make sure this doesn't happen. Instead this new approach uses a private symbol to store the initializer function on the class constructor itself. For the base constructor case, we can simply check for a bit on the constructor function literal to see if we need to emit code that loads and calls this initializer function. Therefore, we don't pay the cost of loading this function in case there are no class fields. For the derived constructor case, there are two possiblities: (a) We are in a super() call directly in the derived constructor: In this case we can do a check similar to the base constructor check, we can check for a bit on the derived constructor and emit code for loading and calling the initializer function. This is usually the common case and we don't pay any cost for not using class fields. (b) We are in a super() call inside an arrow function in the derived constructor: In this case, we /always/ emit code to load and call the initializer function. If the function doesn't exist then we have undefined and we don't call anything. Otherwise we call the function. super() can't be called twice so even if we emit code to load and call the initializer function multiple times, it doesn't matter because it would have already been an error. Bug: v8:5367 Change-Id: I7f77cd6493ff84cf0e430a8c1039bc9ac6941a88 Reviewed-on: https://chromium-review.googlesource.com/781660 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#49628}
-
- 21 Nov, 2017 1 commit
-
-
Clemens Hammacher authored
Currently the SourcePositionTableBuilder requires a Zone because it holds a ZoneVector<byte> of the encoded entries. Since ZoneVector is a suboptimal data structure anyway, and for Liftoff we don't even have a Zone allocated currently, this CL replaces the ZoneVector by std::vector. R=mstarzinger@chromium.org Bug: v8:6600 Change-Id: I8010143e917e2351664e2b53746753b597f4407a Reviewed-on: https://chromium-review.googlesource.com/779181Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49534}
-
- 15 Nov, 2017 1 commit
-
-
Ross McIlroy authored
Removes Isolate from compilation info and instead threads isolate through function calls. This ensures that we can't access the isolate from background thread compilations. BUG=v8:5203 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I9a4e1cd67c4736e36f609360b996fb55166a1c50 Reviewed-on: https://chromium-review.googlesource.com/751745 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#49386}
-
- 27 Oct, 2017 1 commit
-
-
Adam Klein authored
This eliminates the AstValue class, effectively moving its implementation into the Literal AstNode. This should cause no difference in behavior, but it does signal some shifts in the underlying system. Biggest changes include: - Reduction in AST memory usage - No duplicate HeapNumbers in Ignition constant pools - Non-String values are allocated either at constant pool creation time (or at boilerplate creation time for literals), rather than at AstValueFactory::Internalize() time. There are a variety of test-only/debug-only changes due to these switches as well. Bug: v8:6984 Change-Id: I5f178040ce2796d4e7370c24d1063419e1c843a1 Reviewed-on: https://chromium-review.googlesource.com/731111 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#49013}
-
- 25 Oct, 2017 1 commit
-
-
Leszek Swirski authored
Expressions of the form a_0 + a_1 + a_2 + a_3 + ... + a_n seem to be reasonably common for cases such as building templates. However, parsing these expressions results in a n-deep expression tree: ... / + / \ + a_2 / \ a_0 a_1 Traversing this tree during compilation can cause a stack overflow when n is large. Instead, for left-associate operations such as add, we now build up an n-ary node in the parse tree, of the form n-ary + / | \ / | ... \ a_0 a_1 a_n The bytecode compiler can now iterate through the child expressions rather than recursing. This patch only supports arithmetic operations -- subsequent patches will enable the same optimization for logical tests and comma expressions. Bug: v8:6964 Bug: chromium:724961 Bug: chromium:731861 Bug: chromium:752081 Bug: chromium:771653 Bug: chromium:777302 Change-Id: Ie97e4ce42506fe62a7bc4ffbdaa90a9f698352cb Reviewed-on: https://chromium-review.googlesource.com/733120 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#48920}
-
- 19 Oct, 2017 1 commit
-
-
Ross McIlroy authored
Moves the feedback vector slot allocation out of ast-numbering and into bytecode generation directly. This has a couple of benifits, including reduced AST size, avoid code duplication and reduced feedback vector sizes in many cases due to only allocating slots when needed. Also removes AstProperties since this is no longer needed. AstNumbering is now only used to allocate suspend ids for generators. BUG=v8:6921 Change-Id: I103e8593c94ef5b2e56c34ef4f77bd6e7d64796f Reviewed-on: https://chromium-review.googlesource.com/722959 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#48757}
-
- 11 Oct, 2017 1 commit
-
-
Georg Neis authored
This introduces a ToNumeric conversion to the runtime and interpreter. ToNumeric behaves like ToNumber, except that it also lets BigInts pass. Bug: v8:6791 Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7 Reviewed-on: https://chromium-review.googlesource.com/707013 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#48440}
-
- 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}
-
- 12 Sep, 2017 2 commits
-
-
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}
-
Adam Klein authored
As part of that change, make ToNumber return in the accumulator. Bug: v8:6791 Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750 Reviewed-on: https://chromium-review.googlesource.com/658082Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47976}
-
- 08 Sep, 2017 1 commit
-
-
Jaroslav Sevcik authored
The advantage of an explicit Abort that the interpreter and the compiler know that aborting cannot continue or throw or deopt. As a result we generate less code and we do not confuse the compiler if the environment is not set up for throwing (as in the generator dispatch that fails validation in crbug.com/762057). Bug: chromium:762057 Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7 Reviewed-on: https://chromium-review.googlesource.com/657025 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47922}
-
- 07 Sep, 2017 2 commits
-
-
Adam Klein authored
This is in preparation for BigInt, since for BigInt operands the desugared operations will no longer be equivalent. Future CLs can move the handling of these operations further down the pipeline; this is merely a start to get the Parser out of this business. Bug: v8:6791 Change-Id: I9df89e03d3ca2bf627c75fc5efb10463c3ed8cf9 Reviewed-on: https://chromium-review.googlesource.com/653433 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@{#47902}
-
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}
-
- 01 Sep, 2017 1 commit
-
-
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}
-
- 28 Aug, 2017 1 commit
-
-
Camillo Bruni authored
Bug: v8:6211 Change-Id: I0f15c59b7b786ab327e4ab548523095dd85ba83e Reviewed-on: https://chromium-review.googlesource.com/637835Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#47650}
-
- 21 Aug, 2017 1 commit
-
-
Camillo Bruni authored
The quite common empty object literal doesn't need an AllocationSite since it starts off with the general ElementsKind. By using a separate bytecode we can directly instantiate the empty object without jumping to the runtime first. Note: this experimentally disables pretenuring for empty object literals. Depending on the outcome of our benchmarks pretenuring will be enabled again or fully removed for empty object literals. Bug: v8:6211 Change-Id: I2fee81cbefc70865fc436dbd3bc5fc8de04db91c Reviewed-on: https://chromium-review.googlesource.com/577555 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47467}
-
- 08 Aug, 2017 1 commit
-
-
Caitlin Potter authored
A spec change (https://github.com/tc39/proposal-async-iteration/commit/a0dfeba1a8029012b6e964099929b8a157818c9f) introduced a number of Await operations to the spec. In turn, this caused generated bytecode for async generators to grow drastically. This commit moves the Await within AsyncGeneratorYield (https://tc39.github.io/proposal-async-iteration/#sec-asyncgeneratoryield step 5) into a new TFJ builtin, similar in structure to AsyncGeneratorAwait, but instead of resuming the generator on resolution of the Promise, the current generator request's Promise is fulfilled instead. This results in a reduction in generated bytecode without losing any statically available information. BUG=v8:5855 Change-Id: Ib5bcf06132d221beffdea30639a7b4437030143b Reviewed-on: https://chromium-review.googlesource.com/582487 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47224}
-
- 02 Aug, 2017 1 commit
-
-
Julien Brianceau authored
Bug: chromium:750830 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Icab7b5a1c469d5e77d04df8bfca8319784e92af4 Reviewed-on: https://chromium-review.googlesource.com/595655 Commit-Queue: Julien Brianceau <jbriance@cisco.com> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Daniel Ehrenberg <littledan@chromium.org> Cr-Commit-Position: refs/heads/master@{#47072}
-
- 27 Jul, 2017 1 commit
-
-
Leszek Swirski authored
Instead of having feedback vector as a subtype of FixedArray with reserved slots, make it a first-class variable-sized object with a fixed-size header. This allows us to compress counters to ints in the header, rather than forcing them to be Smis. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Icc5f088ffbc2e2651b845bc71ea42060639e3e48 Reviewed-on: https://chromium-review.googlesource.com/585129 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#46935}
-
- 25 Jul, 2017 2 commits
-
-
Caitlin Potter authored
Remove need for shuffling of accumulator and operand registers when suspending a generator BUG=v8:6351 TBR=bmeurer@chromium.org Change-Id: I372509adc03b9781716412b809639554fe16e372 Reviewed-on: https://chromium-review.googlesource.com/578377 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46883}
-
Camillo Bruni authored
Empty Array literals are amongst the most commonly used literal types on our top25 page list. Using a custom bytecode we can drop the boilerplate for empty Array literals alltogether. However, we still need a proper AllocationSite to track ElementsKind transitions. Bug: v8:6211, chromium:746935 Change-Id: I891eaa778e4e81e138e483a65f04ae00ae30bd28 Reviewed-on: https://chromium-review.googlesource.com/580932Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#46875}
-
- 24 Jul, 2017 1 commit
-
-
Benedikt Meurer authored
Properly hook up the (existing) IC slots for the CallWithSpread and ConstructWithSpread bytecodes, and change the interpreter to collect feedback (call counts and regular target function feedback) for those. There's no integration with the Array constructor yet, since that requires some yak shaving to thread through the AllocationSite to the Array constructor stub. Once we have a solution for that, we can also remove the current code duplication in the Call/Construct IC logic. Also properly hook up the newly available feedback in TurboFan. This will fix not only the missing target feedback, but more importantly the tear-up decisions for optimization are correct now in the presence of spread calls, and even more importantly the inlining heurstic has proper call frequencies for those. Some follow-up changes will be necessary to make sure we use the feedback even for corner cases that aren't handled properly yet. Also we should consider collecting feedback about the map of the spread at some point to be able to always inline the spread calls. Bug: v8:6399, v8:6527, v8:6630 Change-Id: I818dbcb411fd3951d8e9d31f5d7e794f8d60fa00 Reviewed-on: https://chromium-review.googlesource.com/582647Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46832}
-
- 20 Jul, 2017 1 commit
-
-
Adam Klein authored
This reverts commit 4851745f. Reason for revert: Top crasher on Canary, see https://crbug.com/746935 Original change's description: > [literals] Introduce CreateEmptyArrayLiteral Bytecode > > Empty Array literals are amongst the most commonly used literal types on our > top25 page list. Using a custom bytecode we can drop the boilerplate for empty > Array literals alltogether. However, we still need a proper AllocationSite to > track ElementsKind transitions. > > Bug: v8:6211 > Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d > Reviewed-on: https://chromium-review.googlesource.com/567079 > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46752} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,cbruni@chromium.org,ishell@chromium.org,rmcilroy@google.com Bug: v8:6211, chromium:746935 Change-Id: Ibf19a923688c071d03bad8661a10e08f8414db56 Reviewed-on: https://chromium-review.googlesource.com/580193 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46804}
-
- 19 Jul, 2017 2 commits
-
-
Ross McIlroy authored
There remained a few of regressions and we didn't see any significant improvement in the real world with this turned on. This CL reverts all the StringConcat bytecode work which landed. BUG=v8:6243 Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8 Reviewed-on: https://chromium-review.googlesource.com/575130 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46769}
-
Camillo Bruni authored
Empty Array literals are amongst the most commonly used literal types on our top25 page list. Using a custom bytecode we can drop the boilerplate for empty Array literals alltogether. However, we still need a proper AllocationSite to track ElementsKind transitions. Bug: v8:6211 Change-Id: Id5dbdac0ea8e24dd474e679c902c6e4a2957af1d Reviewed-on: https://chromium-review.googlesource.com/567079 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46752}
-
- 14 Jul, 2017 2 commits
-
-
Alexey Kozyatinskiy authored
Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
-
Caitlin Potter authored
SuspendFlags was originally used by the suspend operation to determine which field to record the bytecode offset of a suspended generator, and the value the generator was resumed with. For async generators, await operations would use a separate field, in order to preserve the previous yield input value. This was important to ensure `function.sent` continued to function correctly. As function.sent is being retired, this allows the removal of support for that. Given that this was the only real need for SuspendFlags in the first place (with other uses tacked on as a hack), this involves several other changes as well: - Modification of MacroAssembler AssertGeneratorObject. No longer accepts a SuspendFlags parameter to determine which type of check to perform. - Removal of `flags` operand from SuspendGenerator bytecode, and the GeneratorStore js-operator. - Removal of `flags` parameter from ResumeGeneratorTrampoline builtins. - Removal of Runtime functions, interpreter intrinsics and AccessBuilders associated with the [[await_input_or_debug_pos]] field in JSAsyncGeneratorObject, as this field no longer exists. - Addition of a new `Yield` AST node (subclass of Suspend) in order to prevent the need for the other SuspendFlag values. BUG=v8:5855 TBR=bmeurer@chromium.org Change-Id: Iff2881e4742497fe5b774915e988c3d9d8fbe487 Reviewed-on: https://chromium-review.googlesource.com/570485 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46683}
-
- 27 Jun, 2017 1 commit
-
-
Leszek Swirski authored
This reverts commit 87f71769. Reason for revert: Performance regressions https://chromeperf.appspot.com/group_report?rev=46185 Original change's description: > [ignition] Merge bytecode array builder and writer > > Move bytecode array writing logic into the array builder, allowing us to > remove the bytecode array writer and bytecode node, and convert runtime > operand writing to compile-time bytecode operand writing using the > information statically known at compile time. > > Bug: v8:6474 > Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9 > Reviewed-on: https://chromium-review.googlesource.com/533055 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46183} TBR=rmcilroy@chromium.org,leszeks@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:6474 Bug: chromium:736646 Change-Id: I00287b2bbbb8efa5a3141bc9c2906f91a7d33e51 Reviewed-on: https://chromium-review.googlesource.com/549319Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46235}
-
- 23 Jun, 2017 1 commit
-
-
Leszek Swirski authored
Move bytecode array writing logic into the array builder, allowing us to remove the bytecode array writer and bytecode node, and convert runtime operand writing to compile-time bytecode operand writing using the information statically known at compile time. Bug: v8:6474 Change-Id: I210cd9897fd41293745614e4a253c7c251dfffc9 Reviewed-on: https://chromium-review.googlesource.com/533055 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46183}
-
- 22 Jun, 2017 1 commit
-
-
Daniel Ehrenberg authored
In edge cases such as the following, sloppy-mode block-scoped function hoisting is expected to occur: eval(` with({a: 1}) { function a() {} } `) In this case, there should be the equivalent of a var declaration outside of the eval, which gets set to the value of the local function a when the body of the with is executed. Previously, the way that var declarations are hoisted out of eval meant that the assignment to that var was an ordinary DYNAMIC_GLOBAL assignment. However, such a lookup mode meant that the object in the with scope received the assignment! This patch fixes that error by marking the assignments produced by the sloppy mode block scoped function hoisting desugaring so as to generate a different runtime call which skips with scopes. Bug: chromium:720247, v8:5135 Change-Id: Ie36322ddc9ca848bf680163e8c016f50d4597748 Reviewed-on: https://chromium-review.googlesource.com/529230 Commit-Queue: Daniel Ehrenberg <littledan@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#46116}
-
- 06 Jun, 2017 2 commits
-
-
jgruber authored
This CL implements general infrastructure for block coverage together with initial support for if-statements. Coverage output can be generated in lcov format by d8 as follows: $ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js $ genhtml ~/simple-if.lcov -o ~/simple-if $ chrome ~/simple-if/index.html A high level overview of the implementation follows: The parser now collects source ranges unconditionally for relevant AST nodes. Memory overhead is very low and this seemed like the cleanest and simplest alternative. Bytecode generation uses these ranges to allocate coverage slots and insert IncBlockCounter instructions (e.g. at the beginning of then- and else blocks for if-statements). The slot-range mapping is generated here and passed on through CompilationInfo, and is later accessible through the SharedFunctionInfo. The IncBlockCounter bytecode fetches the slot-range mapping (called CoverageInfo) from the shared function info and simply increments the counter. We don't collect native-context-specific counts as they are irrelevant to our use-cases. Coverage information is finally generated on-demand through Coverage::Collect. The only current consumer is a d8 front-end with lcov-style output, but the short-term goal is to expose this through the inspector protocol. BUG=v8:6000 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng Review-Url: https://codereview.chromium.org/2882973002 Cr-Commit-Position: refs/heads/master@{#45737}
-
Mythri authored
Introduces ThrowReferenceErrorIfHole / ThrowSuperNotCalledIfHole / ThrowSuperAlreadyCalledIfNotHole bytecodes to handle hole checks. In the bytecode-graph builder they are handled by introducing a deopt point instead of adding explicit control flow. JumpIfNotHole / JumpIfNotHoleConstant bytecodes are removed since they are no longer required. Bug: v8:4280, v8:6383 Change-Id: I58b70c556b0ffa30e41a0cd44016874c3e9c5fe1 Reviewed-on: https://chromium-review.googlesource.com/509613 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45720}
-
- 02 Jun, 2017 1 commit
-
-
jarin authored
This is a first step towards reducing the number of stores/loads when suspending/resuming a generator. Unfortunately, even for an empty generator, we still use 8 register for various things (try-finally, copies of generator object, parser-introduced temporaries). I will try to get rid of these in separate CLs. Changes: - SuspendGenerator bytecode now takes register list to save. - ResumeGenerator was split into two bytecodes: * Resume generator reads the state out and marks the generator as 'executing'. * RestoreGeneratorRegisters reloads the registers from the generator. + this required adding support for output register list. - Introduced generator_object_ register in the bytecode generator. * in subsequent CLs, I will make better use of it, the goal is to get rid if the .generator_object local variable. - Taught register optimizer to flush unassigned registers. BUG=v8:6379 Review-Url: https://codereview.chromium.org/2894293003 Cr-Commit-Position: refs/heads/master@{#45675}
-
- 24 May, 2017 1 commit
-
-
Ross McIlroy authored
Rather than trying to pre-calculate the number of contexts required during scope analysis, instead just allocate context registers in the register allocator. This reduces frame size a bit due to reusing of registers when the context isn't pushed. BUG=v8:6322, chromium:716265 Change-Id: I145e38fcb3797a3b86c91e90ea9326a6e55b9b89 Reviewed-on: https://chromium-review.googlesource.com/514087Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#45522}
-
- 22 May, 2017 3 commits
-
-
Michael Achenbach authored
This reverts commit bdf70aa0. Reason for revert: Breaks perf testing. Comma missing in json. Original change's description: > [Interpreter] Improve handling of a === true / false. > > Add support for direct jumping on True/False for strict equals of boolean > literals. This improves the score for such comparisons by around 75% on > baseline code, and by around 40x on optimized code for the added performance > test. > > Bug=v8:6403 > > Change-Id: I81ea16a057e081eb6d159cd64c8e8615f65f9abb > Reviewed-on: https://chromium-review.googlesource.com/509570 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Mythri Alle <mythria@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45450} TBR=rmcilroy@chromium.org,mythria@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Bug=v8:6403 Change-Id: I12b1868ba22354d056f38fe36e3c1e5fae5aa1b5 Reviewed-on: https://chromium-review.googlesource.com/509577Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45459}
-
Ross McIlroy authored
Special cases addition expressions where one of the sides is known to be a string to enable chains of string additions to be transformed into a series of ToPrimitiveToString operations followed by a single string concatenation at the end of the chain of additions. This should avoid creating temporary strings for each of the string additions (in essence this is an automated string builder). BUG=v8:6243 Change-Id: I44977d6dad00ee906f251c4bd9cab27e160c09d1 Reviewed-on: https://chromium-review.googlesource.com/493966 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45453}
-
Ross McIlroy authored
Add support for direct jumping on True/False for strict equals of boolean literals. This improves the score for such comparisons by around 75% on baseline code, and by around 40x on optimized code for the added performance test. Bug=v8:6403 Change-Id: I81ea16a057e081eb6d159cd64c8e8615f65f9abb Reviewed-on: https://chromium-review.googlesource.com/509570 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#45450}
-
- 15 May, 2017 1 commit
-
-
Leszek Swirski authored
Introduce a new SwitchSmiTable bytecode for generators, which does a table lookup for the accumulator value in a jump table stored in the constant array pool. This removes the if-else chains at resumable function/loop headers. As a drive-by, add a scoped environment saving struct to the bytecode graph builder. Bug: v8:6351 Bug: v8:6366 Change-Id: I63be15a8b599d6684c7df19dedb8860562678fb0 Reviewed-on: https://chromium-review.googlesource.com/500271 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#45314}
-
- 12 Apr, 2017 1 commit
-
-
Ross McIlroy authored
The BytecodePipeline is no longer used by any optimizers, so remove it and connect the BytecodeArrayBuilder directly to the BytecodeWriter. Also remove some functions from BytecodeNode which are no longer used. BUG=v8:6194 Change-Id: Id2ec94ff1d4db41b108a778100459283fbb2256c Reviewed-on: https://chromium-review.googlesource.com/471528Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#44619}
-
- 11 Apr, 2017 1 commit
-
-
Leszek Swirski authored
Adds a collection of call bytecodes which have an implicit undefined receiver argument, for cases such as global calls where we know that the receiver has to be undefined. This way we can skip an LdaUndefined, decrease bytecode register pressure, and set a more accurate ConvertReceiverMode on the interpreter and TurboFan call. As a side effect, the "normal" Call bytecode now becomes a rare case (only with calls and super property calls), so we get rid of its 0-2 argument special cases and modify CallProperty[N] to use the NotNullOrUndefined ConvertReceiverMode. Reland of https://chromium-review.googlesource.com/c/463287 after fixing tests in https://codereview.chromium.org/2813873002. Change-Id: I314d69c7643ceec6a5750ffdab60dad38dad09e5 Reviewed-on: https://chromium-review.googlesource.com/474752Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#44582}
-