- 17 Oct, 2018 1 commit
-
-
Jaroslav Sevcik authored
Bug: chromium:895799 Change-Id: Icbc06f1fc2362a04e76961f50a8ba4b29080837c Reviewed-on: https://chromium-review.googlesource.com/c/1286336Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56720}
-
- 15 Oct, 2018 1 commit
-
-
Georg Neis authored
There's no ambiguity and the shorter name makes things easier to read. Bug: v8:7790 Change-Id: Ibcf3fd7f38a91e26a83cd335fad0ec80a5fe9be1 Reviewed-on: https://chromium-review.googlesource.com/c/1278392 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#56623}
-
- 12 Oct, 2018 1 commit
-
-
Georg Neis authored
As part of the standard objects serialization, collect the identities of the Array prototype and the Object prototype from all native contexts. This information is then be consulted at compile time instead of having to call Isolate::IsInAnyContext (which accesses the heap). Bug: v8:7790 Change-Id: I26a8271afadfce243a8032e4a012f249ce3c2a60 Reviewed-on: https://chromium-review.googlesource.com/c/1275815 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#56599}
-
- 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}
-
- 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}
-
- 18 May, 2018 1 commit
-
-
Sathya Gunasekaran authored
This is not web compatible, so let's delete the code. Bug: v8:5536 Change-Id: I50506d37dcdff1f7f95577c47adcec653cc1f06e Reviewed-on: https://chromium-review.googlesource.com/1064740 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#53264}
-
- 05 Apr, 2018 1 commit
-
-
Peter Marshall authored
This is a reland of 63ecddc8 Original change's description: > [runtime] Remove the construct_stub field of the SFI > > Don't dispatch based on the construct_stub field anymore. Rather than > read it out and jump to the construct stub, we can switch on the > builtin_id. > > Builtins will always have builtin_id as a Smi, so this signals we need > to jump to JSBuiltinsConstructStub. The only exception is for uncompiled > functions, which will have kCompileLazy as the builtin_id, but need to > jump to the generic stub instead. > > API function calls will have a FunctionTemplateInfo in the SFI > function_data field, and need to go to the builtins stub as well. > > The final case is everything else, which should go to the generic stub. > > Bug: v8:7503 > Change-Id: I14790a5f9784dc0d940bf10a05f5310026e1d482 > Reviewed-on: https://chromium-review.googlesource.com/980941 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52345} TBR=bmeurer@chromium.org Bug: v8:7503 Change-Id: Ie46bfb0af173ad7ac8cbdfeed1865e60f3f413f7 Reviewed-on: https://chromium-review.googlesource.com/997712Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#52389}
-
- 04 Apr, 2018 3 commits
-
-
Ross McIlroy authored
With the Ignition + Turbofan pipeline there is very little overlap between the data needed for unoptimized compilation and optimized compilation. As a result, it is cleaner to split up the CompilationInfo into UnoptimizedCompilationInfo and OptimizedCompilationInfo. Doing so also necessitate splitting up CompilationJob into UnoptimizedCompilationJob and OptimizedCompilationJob - again there is not much overlap so this seems cleaner. Change-Id: I1056ad520937b7f8582e4fc3ca8f4910742de30a Reviewed-on: https://chromium-review.googlesource.com/995895 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52369}
-
Michael Achenbach authored
This reverts commit 63ecddc8. Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20internal%20snapshot/builds/14773 Original change's description: > [runtime] Remove the construct_stub field of the SFI > > Don't dispatch based on the construct_stub field anymore. Rather than > read it out and jump to the construct stub, we can switch on the > builtin_id. > > Builtins will always have builtin_id as a Smi, so this signals we need > to jump to JSBuiltinsConstructStub. The only exception is for uncompiled > functions, which will have kCompileLazy as the builtin_id, but need to > jump to the generic stub instead. > > API function calls will have a FunctionTemplateInfo in the SFI > function_data field, and need to go to the builtins stub as well. > > The final case is everything else, which should go to the generic stub. > > Bug: v8:7503 > Change-Id: I14790a5f9784dc0d940bf10a05f5310026e1d482 > Reviewed-on: https://chromium-review.googlesource.com/980941 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52345} TBR=petermarshall@chromium.org,leszeks@chromium.org,bmeurer@chromium.org Change-Id: I2031913ab5a12018ad932f920792aa1f6faa5e22 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7503 Reviewed-on: https://chromium-review.googlesource.com/995293Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#52346}
-
Peter Marshall authored
Don't dispatch based on the construct_stub field anymore. Rather than read it out and jump to the construct stub, we can switch on the builtin_id. Builtins will always have builtin_id as a Smi, so this signals we need to jump to JSBuiltinsConstructStub. The only exception is for uncompiled functions, which will have kCompileLazy as the builtin_id, but need to jump to the generic stub instead. API function calls will have a FunctionTemplateInfo in the SFI function_data field, and need to go to the builtins stub as well. The final case is everything else, which should go to the generic stub. Bug: v8:7503 Change-Id: I14790a5f9784dc0d940bf10a05f5310026e1d482 Reviewed-on: https://chromium-review.googlesource.com/980941Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#52345}
-
- 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}
-
- 23 Mar, 2018 1 commit
-
-
Peter Marshall authored
Part of ongoing work to remove the construct_stub. For non-constructable functions, don't use the non-constructable stub, instead handle non-constructables explicitly in ConstructFunction. Bug: v8:7503 Change-Id: I24aa7c2d5e934d5e80cd96afaf005342773d57af Reviewed-on: https://chromium-review.googlesource.com/975961 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52185}
-
- 22 Feb, 2018 1 commit
-
-
Benedikt Meurer authored
This is preparatory cleanup work for eventually tracking the functions (rather than concrete closures) in the CALL_IC, also for builtins like the default PromiseCapability [[Resolve]] and [[Reject]] functions. It adds a new FeedbackCell type, which is used by JSFunctions consistently now to reference the feedback vector (or undefined if not the function is not compiled yet or is a native/asm.js function). This also changes the calling convention for FastNewClosure builtin and the JSCreateClosure operator in TurboFan to carry the FeedbackCell here instead of the parent FeedbackVector and the slot index. In addition we eliminate the now unused %InterpreterNewClosure runtime function. Bug: v8:2206, v8:7253, v8:7310 Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656 Reviewed-on: https://chromium-review.googlesource.com/928403 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#51474}
-
- 29 Nov, 2017 1 commit
-
-
Benedikt Meurer authored
The two helper functions CanBePrimitive and NeedsConvertReceiver did essentially the same, just in a slightly different way, and both weren't really robust wrt. to the list of JSConstruct* and JSCreate* operators that they were handling. There's now a single helper in the NodeProperties and a couple of extra macro lists to keep this list up to date more easily. Drive-by-fix: Also moved the CanBeNullOrUndefined helper to the NodeProperties class. Bug: v8:5267, v8:7109 Change-Id: Ibbf387040e3f424ee224c53fac15c2b3207b1926 Reviewed-on: https://chromium-review.googlesource.com/793734Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49695}
-
- 14 Nov, 2017 1 commit
-
-
Michael Stanton authored
This reverts commit f010b28f. Reason for revert: Introduces a clusterfuzz issue and CAnary crash Original change's description: > [TurboFan] Diagnostic code to track down bug in representation selection > > We need to characterize the types of dead (IrOpcode::kDead) nodes > introduced in compilation phases prior to representation selection. > Normally, a dead node isn't expected at the start of this phase. The > question is, which phase introduced the dead node and failed to > deal with it properly? > > Bug: chromium:780658 > Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e > Reviewed-on: https://chromium-review.googlesource.com/765968 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Commit-Queue: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49328} TBR=mvstanton@chromium.org,mstarzinger@chromium.org Change-Id: I5d628eb1de630ce4a353b6ef0f80fd74ad740f17 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:780658 Reviewed-on: https://chromium-review.googlesource.com/768747Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49347}
-
- 13 Nov, 2017 1 commit
-
-
Mike Stanton authored
We need to characterize the types of dead (IrOpcode::kDead) nodes introduced in compilation phases prior to representation selection. Normally, a dead node isn't expected at the start of this phase. The question is, which phase introduced the dead node and failed to deal with it properly? Bug: chromium:780658 Change-Id: Ief5b45480bb7d704a2d09dafd60b5d389e0fd42e Reviewed-on: https://chromium-review.googlesource.com/765968Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#49328}
-
- 27 Oct, 2017 1 commit
-
-
Jaroslav Sevcik authored
This enables proper wiring into ithe control flow chain. Bug: v8:7002,chromium:777574 Change-Id: Idba59944ff6ab3c10c204bb74ace61d812e6297c Reviewed-on: https://chromium-review.googlesource.com/738183Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#48990}
-
- 17 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
So far the inlining of Function#bind into TurboFan optimized code was limited to cases where TurboFan could infer the constant JSFunction that was bound. However we can easily extend that to cover JSBoundFunction as well, and obviously also take the LOAD_IC feedback if we don't have a known JSFunction or JSBoundFunction. This adds a new operator JSCreateBoundFunction that contains the logic for the creation of the bound function object and the arguments. On the micro-benchmarks we go from functionBindParameter0: 1239 ms. functionBindConstant0: 478 ms. functionBindBoundConstant0: 1256 ms. functionBindParameter1: 1278 ms. functionBindConstant1: 475 ms. functionBindBoundConstant1: 1253 ms. functionBindParameter2: 1431 ms. functionBindConstant2: 616 ms. functionBindBoundConstant2: 1437 ms. to functionBindParameter0: 462 ms. functionBindConstant0: 485 ms. functionBindBoundConstant0: 474 ms. functionBindParameter1: 478 ms. functionBindConstant1: 474 ms. functionBindBoundConstant1: 474 ms. functionBindParameter2: 617 ms. functionBindConstant2: 614 ms. functionBindBoundConstant2: 616 ms. which is a ~2.5x improvement. On the jshint benchmark in the web-tooling-benchmark we observe a 2-3% improvement, which corresponds to the time we had seen it running in the generic version. Bug: v8:6936, v8:6946 Change-Id: I940d13220ff35ae602dbaa33349ba4bbe0c9a9d3 Reviewed-on: https://chromium-review.googlesource.com/723080Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48639}
-
- 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}
-
- 17 Aug, 2017 3 commits
-
-
Ross McIlroy authored
This is a reland of 21da12a9 Original change's description: > [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile > > Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions > and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared) > function. The code in compiler.cc is refactored to use this function to compile > the SharedFunctionInfo when compiling a JSFunction. > > Also does some other cleanup: > - Removes CompileUnoptimizedFunction and inlines into new Compiler function > - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and > out of FinalizeUnoptimizedCompile. > > BUG=v8:6409 > > Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3 > Reviewed-on: https://chromium-review.googlesource.com/613760 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47394} TBR=yangguo@chromium.org TBR=jarin@chromium.org Bug: v8:6409 Change-Id: If2eae66a85f129e746a5ca5c04935540f3f86b04 Reviewed-on: https://chromium-review.googlesource.com/618886Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47399}
-
Ross McIlroy authored
This reverts commit 21da12a9. Reason for revert: Failing on arm64 simulator Original change's description: > [Compiler] Remove CompileDebugCode and EnsureBytecode and replace with Compile > > Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions > and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared) > function. The code in compiler.cc is refactored to use this function to compile > the SharedFunctionInfo when compiling a JSFunction. > > Also does some other cleanup: > - Removes CompileUnoptimizedFunction and inlines into new Compiler function > - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and > out of FinalizeUnoptimizedCompile. > > BUG=v8:6409 > > Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3 > Reviewed-on: https://chromium-review.googlesource.com/613760 > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47394} TBR=rmcilroy@chromium.org,yangguo@chromium.org,jarin@chromium.org,leszeks@chromium.org Change-Id: I4ba63e82417a185f1528ff2633eb6c8872fbbfe5 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6409 Reviewed-on: https://chromium-review.googlesource.com/618687Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47397}
-
Ross McIlroy authored
Removes the Compiler::CompileDebugCode and Compiler::EnsureBytecode functions and replaces them with a Compiler::Compile(Handle<SharedFunctionInfo> shared) function. The code in compiler.cc is refactored to use this function to compile the SharedFunctionInfo when compiling a JSFunction. Also does some other cleanup: - Removes CompileUnoptimizedFunction and inlines into new Compiler function - Moves code to create top level SharedFunctionInfo into CompilerTopLevel and out of FinalizeUnoptimizedCompile. BUG=v8:6409 Change-Id: Ic54afcd8eb005c17f3ae6b2355060846e3091ca3 Reviewed-on: https://chromium-review.googlesource.com/613760 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#47394}
-
- 10 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Deletes AstGraphBuilder and associated classes now that it is unreachable. The following classes are also removed: - ControlBuilders - JSFrameSpecialization - AstLoopAssignmentAnalysis Also removes flags from compilation-info which are no longer used, and removes the no-deoptimization paths from TypedOptimization, JsTypedLowering, JSIntrinsicLowering and JSBuiltinLowering. BUG=v8:6409 Change-Id: I63986e8e3497bf63c4a27ea8ae827b8a633d4a26 Reviewed-on: https://chromium-review.googlesource.com/583652 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47284}
-
- 09 Aug, 2017 2 commits
-
-
Mythri authored
Currently, we do not inline recursive functions. This is in general a good idea but could be useful in some cases. For example, in rayTrace there is a class.create function to create new classes, which basically calls the initialize function on the object. When there are classes which instantiate other classes this leads to recursion. These are really small functions (within the small function budget) and it is good to inline them. Allowing such functions to inline improves the score on rayTrace by 12-16% and box2d by 24-30%. There is also an absolute limit on the maximum levels of inlining to avoid any corner cases and to ensure inlining always terminates. Bug: v8:6682 Change-Id: I6784f68d6395097d126c0850b1a1336b6583d958 Reviewed-on: https://chromium-review.googlesource.com/608235Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#47255}
-
Mostyn Bramley-Moore authored
To speed up compilation times, jumbo allows files to be compiled together. This is a well known method ("unity builds") to both compile faster and create a poor man's "full program optimization". We are only interested in compile times. Background: https://chromium.googlesource.com/chromium/src/+/master/docs/jumbo.md Note that jumbo builds are not enabled by default. To try this out, add use_jumbo_build=true to your GN args. BUG=chromium:746958 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: Ieb9fdccb6c135e9806dbed91c09a29aa8b8bee11 Reviewed-on: https://chromium-review.googlesource.com/579090 Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com> Reviewed-by:
Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#47239}
-
- 04 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Moves the construction of CompilationInfo for unoptimized code into GenerateUnoptimizedCode in preparation for making it owned by the unoptimized compilation jobs (to be done in a followup CL). This CL also adds a new constructor for creation of unoptimized CompilationInfos with fields correctly initialized and updates the existing constructor to he exclusively for optimized compilation. Finally, also moves the call to RecordFunctionCompilation with LAZY_COMPILE_TAG recording into FinalizeUnoptimizedCompilationJob where it is called for other unoptimized compiles. BUG=v8:5203,v8:6659 Change-Id: Icfd7f56588073f2fc547e002db9fa99843ed2e8b Reviewed-on: https://chromium-review.googlesource.com/598908 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47160}
-
- 03 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Don't hold a pointer to parse_info in compilation_info, and instead explicitly add the fields needed in compiation_info. The intention is to make ParseInfo only actually needed for parsing, and eventually make it possible to compile with only a CompileInfo. BUG=v8:5203 Change-Id: Iecd39245e44c218874401c3991eeaf3ceef2816f Reviewed-on: https://chromium-review.googlesource.com/595738Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#47119}
-
- 01 Aug, 2017 1 commit
-
-
jgruber authored
This is a reland of 2f79e035 Original change's description: > [builtins] Remove Builtins::Name() accessors > > Instead of auto-generating the Name() convenience accessor, use a macro to > avoid wasting code space. > > BUILTIN_CODE(isolate, Name) > > expands to > > isolate->builtins()->builtin_handle(Builtins::kName); > > This reduces the size of libv8.so by 134,752 bytes on a x64 release build. > > Bug: v8:6624 > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f > Reviewed-on: https://chromium-review.googlesource.com/593607 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47010} TBR=bmeurer@chromium.org,ahaas@chromium.org Bug: v8:6624 Change-Id: I4733731e56dc8873ee06c2b36cac1918c0a658b2 Reviewed-on: https://chromium-review.googlesource.com/594087 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47037}
-
- 31 Jul, 2017 2 commits
-
-
Jakob Gruber authored
This reverts commit 2f79e035. Reason for revert: Conflicts with successor CL. Original change's description: > [builtins] Remove Builtins::Name() accessors > > Instead of auto-generating the Name() convenience accessor, use a macro to > avoid wasting code space. > > BUILTIN_CODE(isolate, Name) > > expands to > > isolate->builtins()->builtin_handle(Builtins::kName); > > This reduces the size of libv8.so by 134,752 bytes on a x64 release build. > > Bug: v8:6624 > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f > Reviewed-on: https://chromium-review.googlesource.com/593607 > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#47010} TBR=yangguo@chromium.org,ahaas@chromium.org,jgruber@chromium.org,bmeurer@chromium.org Change-Id: Ia9ef5c755b26c3f4e143d87a7c51033614ea435e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6624 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/594048Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47012}
-
jgruber authored
Instead of auto-generating the Name() convenience accessor, use a macro to avoid wasting code space. BUILTIN_CODE(isolate, Name) expands to isolate->builtins()->builtin_handle(Builtins::kName); This reduces the size of libv8.so by 134,752 bytes on a x64 release build. Bug: v8:6624 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f Reviewed-on: https://chromium-review.googlesource.com/593607Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#47010}
-
- 26 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Reland of https://chromium-review.googlesource.com/c/543042/. Now the OSR phase is only used when OSRing from the ast graph builder. When OSRing from Turbofan, the implementation is now in the graph building phase, at the beginning of the VisitBytecode function. We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, nor nodes for the possible code of the OSRed function which is before the OSRed loops. The trimming and reducing of the OSR phase is not done either. This change in the way the way the OSR is done enabled to remove the workaround to the bug mentioned below. Bug: v8:6112 Bug: v8:6518 Change-Id: Ia02f2138f54fc79cab2f02fed68d9bb522d6ce14 Reviewed-on: https://chromium-review.googlesource.com/584756 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46899}
-
- 21 Jul, 2017 2 commits
-
-
Ross McIlroy authored
This reverts commit 69c8f16d. Reason for revert: Causing crashes on Clusterfuzz - http://crbug.com/747154 BUG=chromium:747154 Original change's description: > [Turbofan] Merged the OSR phase into the graph building phase. > > Now the OSR phase is only used when OSRing from the ast graph builder. > When OSRing from Turbofan, the implementation is now in the graph > building phase, at the beginning of the VisitBytecode function. > We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, > nor nodes for the possible code of the OSRed function which is before > the OSRed loops. > > The trimming and reducing of the OSR phase is not done either. This > change in the way the way the OSR is done enabled to remove the > workaround to the bug mentioned below. > > Bug: v8:6112 > Bug: v8:6518 > Change-Id: I1c9231810b923486d55ea618d550d981d695d797 > Reviewed-on: https://chromium-review.googlesource.com/543042 > Commit-Queue: Alexandre Talon <alexandret@google.com> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46801} TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org,alexandret@google.com Change-Id: Ifa9bf5d86e888a47cad7fb10446b36fda5029604 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6112, v8:6518 Reviewed-on: https://chromium-review.googlesource.com/581288Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46817}
-
Ross McIlroy authored
Removes the SharedFunctionInfo field from the ParseInfo structure. Instead require a SharedFunctionInfo to be explicitly passed to ParseFunction. Also renames GetUnoptimizedCode to CompileUnoptimizedFunction to make it clear it should only be called for non-top-level code. BUG=v8:5203 Change-Id: Ibce016e6a5290c3685f7f0a2f5fb1eb2df2ffc3b Reviewed-on: https://chromium-review.googlesource.com/574589 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#46814}
-
- 20 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Now the OSR phase is only used when OSRing from the ast graph builder. When OSRing from Turbofan, the implementation is now in the graph building phase, at the beginning of the VisitBytecode function. We are no longer generating any OSRLoopEntry or OSRNormalEntry nodes, nor nodes for the possible code of the OSRed function which is before the OSRed loops. The trimming and reducing of the OSR phase is not done either. This change in the way the way the OSR is done enabled to remove the workaround to the bug mentioned below. Bug: v8:6112 Bug: v8:6518 Change-Id: I1c9231810b923486d55ea618d550d981d695d797 Reviewed-on: https://chromium-review.googlesource.com/543042 Commit-Queue: Alexandre Talon <alexandret@google.com> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46801}
-
- 13 Jul, 2017 1 commit
-
-
Adam Klein authored
The tail call implementation is hidden behind the --harmony-tailcalls flag, which is off-by-default (and has been unstaged since February). It is known to be broken in a variety of cases, including clusterfuzz security issues (see sample Chromium issues below). To avoid letting the implementation bitrot further on trunk, this patch removes it. Bug: v8:4698, chromium:636914, chromium:724746 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I9cb547101456a582374fdf7b1a3f044a9ef33e5c Reviewed-on: https://chromium-review.googlesource.com/569069 Commit-Queue: Adam Klein <adamk@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46651}
-
- 08 Jun, 2017 1 commit
-
-
Mythri authored
ThrowIfHole bytecodes were handled by introducing deopt points to check for a hole. To avoid deopt loops a hole check protector was used to generate control flow if there was a deopt due to a hole. However, the normal control flow version should be as fast as the deopt version in general. The deopt version could potentially consume less compile time but it may not be worth the complexity added. Hence simplifying it to only construct the control flow. Bug: v8:6383 Change-Id: Icace11f7a6e21e64e1cebd104496e3f559bc85f7 Reviewed-on: https://chromium-review.googlesource.com/525573Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#45783}
-
- 06 Jun, 2017 1 commit
-
-
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}
-
- 31 May, 2017 1 commit
-
-
jgruber authored
DebugInfo was very closely tied to break point support: * It contained only information relevant to break points. * It was created and freed by break point implementation. * Existence of a DebugInfo on the shared function info implied existence of break points. This CL is a step towards making DebugInfo usable by other debugging functionality such as block coverage by decoupling it from break point support, which is now only one kind of information stored on the DebugInfo object. BUG=v8:6000 Review-Url: https://codereview.chromium.org/2909893002 Cr-Commit-Position: refs/heads/master@{#45640}
-