- 11 Jan, 2018 1 commit
-
-
Leszek Swirski authored
This makes RestoreGeneratorRegisters do a fuller resume process: update the state register to indicate that it is now executing, and update the accumulator with the input_or_debug_pos of the generator - i.e., perform the boilerplate generator resuming in one bytecode instead of several. Change-Id: Ia87b6766ac023064b40d3e9a143e7b32118ea3a0 Reviewed-on: https://chromium-review.googlesource.com/859770 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#50499}
-
- 30 Nov, 2017 1 commit
-
-
Benedikt Meurer authored
Strings are immutable in JavaScript land (contrast with the runtime, where we can truncate strings that haven't escaped to JavaScript yet), so the length of a String is immutable. Thus loading the length of a String is a pure operation and should be expressed as such (i.e. doesn't depend on control or effect). The StringLength operator does exactly this and is hooked up to the effect chain in the EffectControlLinearizer. This will eventually allow us to simplify the optimization of string concatention and other operations that are a bit cumbersome in TurboFan currently, and it will also allow us to optimize string operations across effectful operations, for example combining multiple invocations to String#slice with the same inputs. Bug: v8:5269, v8:6936, v8:7109, v8:7137 Change-Id: Iffcccbb0c7fc4cfe1281c10e7af24b40eba4c987 Reviewed-on: https://chromium-review.googlesource.com/799690Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49731}
-
- 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 3 commits
-
-
Georg Neis authored
This introduces a JSBitwiseNot operator and lowers it either to a speculative xor with -1 (when we have Number feedback) or to a stub call. The stub is also new. Bug: v8:6791 Change-Id: I362e52de8a741dc5db044c406543878e407eb2ed Reviewed-on: https://chromium-review.googlesource.com/778839 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49539}
-
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}
-
Georg Neis authored
TBR: rmcilroy@chromium.org Bug: v8:6791 Change-Id: I4ac2bdce353d987a2fe45149d8556b6591569a01 Reviewed-on: https://chromium-review.googlesource.com/771191 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#49528}
-
- 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}
-
- 19 Oct, 2017 1 commit
-
-
Mike Stanton authored
Because the toboolean operator may lower to a builtin call (which is effectful in turbofan parlance after effect control linearization), it really should be encoded as a simplified operator, which can be optimized with respect for the effect chain in linearization. No new functionality here, rather a furniture rearrangement in the TurboFan node structure. Bug: v8:6929 Change-Id: I371fd22941397d5c28d13bded2738161d8da8275 Reviewed-on: https://chromium-review.googlesource.com/725721Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48727}
-
- 16 Oct, 2017 1 commit
-
-
Mike Stanton authored
Because the typeof operator may lower to a builtin call (which is effectful in turbofan parlance after effect control linearization), it really should be encoded as a simplified operator, which can be optimized with respect for the effect chain in linearization. No new functionality here, rather a furniture rearrangement in the TurboFan node structure. BUG=v8:6929 Change-Id: I38593e10956ebd57cecdd606c35f3f73efb1327e Reviewed-on: https://chromium-review.googlesource.com/718745Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#48613}
-
- 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
-
-
Benedikt Meurer authored
There's no need to have the StringLengthProtector as a PropertyCell, since it's only used to guard against deoptimization loops. This also allows us to remove the use of the CompilationDependencies from the JSTypedLowering. R=jarin@chromium.org Bug: v8:6759 Change-Id: I54a37be6b8064ca3475e3b321f928b6a9903f209 Tbr: mstarzinger@chromium.org Reviewed-on: https://chromium-review.googlesource.com/637303 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47633}
-
- 11 Aug, 2017 1 commit
-
-
Benedikt Meurer authored
These operators were only used by the old asm.js pipeline (with fullcodegen and the AstGraphBuilder). When going through the new pipeline, accesses to TypedArrays are handled by the native context specialization during inlining. Bug: v8:6409 Change-Id: Ib9b888c0b96f297a335580ee42dfa951bde566be Reviewed-on: https://chromium-review.googlesource.com/612347Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#47322}
-
- 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}
-
- 19 Jul, 2017 1 commit
-
-
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}
-
- 11 Jul, 2017 1 commit
-
-
Alexandre Talon authored
Each reducer now has a virtual reducer_name function, returning its name (the name of the class containing this reducer). This gets displayed when using the --trace_turbo_reduction flag. Also when using this flags more messages are displayed. Actually when a node is replaced in-place (which is called an update of the node), other reducers can still update it right after the in-place replacement. When a node is really replaced (not in-place), then we stop trying to apply reducers to it before we propagate the reduction through the relevant nodes. Before a message got printed only for the last reduction it went through. So in case a node was reduced in-place several times in a row, only the last update was printed, or none at all if after being reduced in-place it got reduced by being replaced by another node: only the non-in-place replacement was showed. Now each time an in-place reduction is applied to a node, a message gets printed. Bug: Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Alexandre Talon <alexandret@google.com> Cr-Commit-Position: refs/heads/master@{#46552}
-
- 21 Jun, 2017 1 commit
-
-
Ross McIlroy authored
Adds typed lowering of JSStringConcat to ConsString allocation if the following conditions hold: - All concatinations will result in a ConsString of >= ConString::kMinLength - No concatinations will result in a empty string in the RHS unless there is a sequential string in the LHS. This also means JSStringConcat needs an eager checkpoint since it can deopt if throwing a RangeError when the string length protector is valid. BUG=v8:6243 Change-Id: I01ca79f884df467c10f2c032c72d51b5199c1a3c Reviewed-on: https://chromium-review.googlesource.com/526636 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#46093}
-
- 19 Jun, 2017 1 commit
-
-
bmeurer authored
We need to constant-fold JSHasInPrototypeChain nodes early during inlining, otherwise we already miss a couple of optimization opportunities if we wait until after typing. This moves the constant-folding part of the JSHasInPrototypeChain lowering back to JSNativeContextSpecialization, where it was before the changes in https://codereview.chromium.org/2934893002 (part of JSOrdinaryHasInstance lowering back then). BUG=v8:5269,v8:5989,v8:6483,chromium:733158 R=jgruber@chromium.org Review-Url: https://codereview.chromium.org/2943293002 Cr-Commit-Position: refs/heads/master@{#45989}
-
- 13 Jun, 2017 1 commit
-
-
bmeurer authored
Port the baseline implementation of Object.prototype.isPrototypeOf to the CodeStubAssembler, sharing the existing prototype chain lookup logic with the instanceof / OrdinaryHasInstance implementation. Based on that, do the same in TurboFan, introducing a new JSHasInPrototypeChain operator, which encapsulates the central prototype chain walk logic. This speeds up Object.prototype.isPrototypeOf by more than a factor of four, so that the code A.prototype.isPrototypeOf(a) is now performance-wise on par with a instanceof A for the case where A is a regular constructor function and a is an instance of A. Since instanceof does more than just the fundamental prototype chain lookup, it was discovered in Node core that O.p.isPrototypeOf would be a more appropriate alternative for certain sanity checks, since it's less vulnerable to monkey-patching. In addition, the Object builtin would also avoid the performance-cliff associated with instanceof (due to the Symbol.hasInstance hook), as for example hit by https://github.com/nodejs/node/pull/13403#issuecomment-305915874. The main blocker was the missing performance of isPrototypeOf, since it was still a JS builtin backed by a runtime call. This CL also adds more test coverage for the Object.prototype.isPrototypeOf builtin, especially when called from optimized code. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng BUG=v8:5269,v8:5989,v8:6483 R=jgruber@chromium.org Review-Url: https://codereview.chromium.org/2934893002 Cr-Commit-Position: refs/heads/master@{#45925}
-
- 08 Jun, 2017 1 commit
-
-
Ross McIlroy authored
Add the ability for the typer to track whether a string could be the empty string. This is needed for typed lowering of JSStringConcat since we can't create cons string chain with the empty string in arbitrary positions. The ToPrimitiveToString bytecode handler is modified to collect feedback on whether it has ever seen the empty string, which is used by SpeculativeToPrimitiveToString to ensure that the output is non-empty (or depot) which will subsiquently be used to enable inline cons-string creation for the JSStringConcat operator in typed lowering in a subsiquent CL. BUG=v8:6243 Change-Id: I41b99b59798993f756aada8cff90fb137d65ea52 Reviewed-on: https://chromium-review.googlesource.com/522122 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#45786}
-
- 07 Jun, 2017 1 commit
-
-
Ross McIlroy authored
Adds support for lowering of ToPrimitiveToString and StringConcat bytecodes to the corresponding builtins. As part of this, moves the interpreter implementation of these operations into the appropriate builtin generators and add builtin support for them. Also adds TailCallRuntimeN operator to code-assembler which enables tail calling a runtime function when the arguments have already been pushed onto the stack. BUG=v8:6243 Change-Id: Id5c851bc42e4ff490d9a23a8990ae331c7eac73e Reviewed-on: https://chromium-review.googlesource.com/515362 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#45756}
-
- 18 May, 2017 2 commits
-
-
bmeurer authored
For additions like a+'' or ''+a where we have String feedback on the JSAdd, we can drop the concatenation and just check that a is a valid String already (via CheckString). BUG=v8:6259 R=petermarshall@chromium.org Review-Url: https://codereview.chromium.org/2894563002 Cr-Commit-Position: refs/heads/master@{#45395}
-
bmeurer authored
We already had an optimization to turn Function.prototype.apply with arguments object, i.e. function foo() { return bar.apply(this, arguments); } into a special operator JSCallForwardVarargs, which avoids the allocation and deconstruction of the arguments object, but just passes along the incoming parameters. We can do the same for rest parameters and spread calls/constructs, i.e. class A extends B { constructor(...args) { super(...args); } } or function foo(...args) { return bar(1, 2, 3, ...args); } where we basically pass along the parameters (plus maybe additional statically known parameters). For this, we introduce a new JSConstructForwardVarargs operator and generalize the CallForwardVarargs builtins that are backing this. BUG=v8:6407,v8:6278,v8:6344 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2890023004 Cr-Commit-Position: refs/heads/master@{#45388}
-
- 03 May, 2017 1 commit
-
-
neis authored
This is just a refactoring, no changes in behavior. BUG=v8:1569 Review-Url: https://codereview.chromium.org/2839623003 Cr-Commit-Position: refs/heads/master@{#45071}
-
- 07 Apr, 2017 1 commit
-
-
bmeurer authored
Add a dedicated operator for ToNumber(x) with feedback instead of translating to SpeculativeNumberMultiply(x,1), which allows us to treat the case where x is already a Number specially, ignoring the feedback on the operator. This recovers most of the regression in the crypto benchmark. BUG=chromium:709398,v8:6214,v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2802113003 Cr-Commit-Position: refs/heads/master@{#44484}
-
- 29 Mar, 2017 1 commit
-
-
bmeurer authored
Now that Ignition has the dedicated TestTypeOf operator, there's not really a point in doing the typeof with abstract/strict equal combining in TurboFan anymore. In fact it's counter-productive to do so, as it might try to cover typeof comparisons in cases where it's better to just compute the typeof once, i.e.: let x = typeof a, y = typeof b; if (x === y) { if (x === 'string') { ... } } Here we would combine the second comparison into an ObjectIsString, and still compute the typeof a. R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2780953003 Cr-Commit-Position: refs/heads/master@{#44220}
-
- 07 Mar, 2017 1 commit
-
-
Michael Starzinger authored
The parser already changes all negative equality comparison operations to their positive pendants in {ParserBase::ParseBinaryExpression}. No other source of the Token::NE exists in the system. We can remove all handling from the compiler and interpreter backends. R=bmeurer@chromium.org Change-Id: I58722c08dd8e498f20c65886fce86b8172737b10 Reviewed-on: https://chromium-review.googlesource.com/449716Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43627}
-
- 03 Mar, 2017 1 commit
-
-
bmeurer authored
We don't need the JSStrictNotEqual operator in the compiler, because this is never generated by the BytecodeGraphBuilder, and the code in the AstGraphBuilder was dead code. Also remove the backing builtin StrictNotEqual. R=mstarzinger@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2727003006 Cr-Commit-Position: refs/heads/master@{#43594}
-
- 28 Feb, 2017 1 commit
-
-
Michael Starzinger authored
This handles relational comparison operations (no equality yet) having number feedback during the early type-hint lowering (i.e. during graph construction). R=jarin@chromium.org Change-Id: Ia276d1d7c5931f1e92f31e4e24c181d82d48a138 Reviewed-on: https://chromium-review.googlesource.com/446762Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43471}
-
- 22 Feb, 2017 2 commits
-
-
Michael Starzinger authored
This reverts commit 14de196a. Reason for revert: Tanks Mandreel, fix is in flight, but we want a stable baseline first. Will reland again next week. Original change's description: > [turbofan] Handle comparison operations in early lowering. > > This handles relational comparison operations (no equality yet) having > number feedback during the early type-hint lowering (i.e. during graph > construction). > > R=bmeurer@chromium.org > > Change-Id: I0ac1539f85de1770c3d518855754550932f6fcd3 > Reviewed-on: https://chromium-review.googlesource.com/445716 > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#43365} TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org,rmcilroy@chromium.org,v8-reviews@googlegroups.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: I103d976c9b9b73ca67af6f6a32ea47a52d04c123 Reviewed-on: https://chromium-review.googlesource.com/446358Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43375}
-
Michael Starzinger authored
This handles relational comparison operations (no equality yet) having number feedback during the early type-hint lowering (i.e. during graph construction). R=bmeurer@chromium.org Change-Id: I0ac1539f85de1770c3d518855754550932f6fcd3 Reviewed-on: https://chromium-review.googlesource.com/445716Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43365}
-
- 20 Feb, 2017 2 commits
-
-
Michael Starzinger authored
This reverts commit f967d3e9. Reason for revert: Tanks Mandreel again. Needs investigation. Original change's description: > [turbofan] Handle comparison operations in early lowering. > > This handles comparison operations (equality and relational) having > number feedback during the early type-hint lowering (i.e. during graph > construction). > > R=bmeurer@chromium.org > > Change-Id: I97afd6c0d78a790ce38b731f2532ca18d812a32c > Reviewed-on: https://chromium-review.googlesource.com/444766 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#43315} TBR=mstarzinger@chromium.org,bmeurer@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Change-Id: Iec335827fe841ac6f1bd45ce095d0a741b2ff5b5 Reviewed-on: https://chromium-review.googlesource.com/445177Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43326}
-
Michael Starzinger authored
This handles comparison operations (equality and relational) having number feedback during the early type-hint lowering (i.e. during graph construction). R=bmeurer@chromium.org Change-Id: I97afd6c0d78a790ce38b731f2532ca18d812a32c Reviewed-on: https://chromium-review.googlesource.com/444766Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43315}
-
- 16 Feb, 2017 1 commit
-
-
Michael Starzinger authored
This handles arithmetic addition operations during the early type-hint lowering (i.e. during graph construction). The string addition case is still handled by {JSTypedLowering} as it needs static type information. R=bmeurer@chromium.org Change-Id: I9df47dfc5bf7613c51f6d803ab43d5d3f6c21be8 Reviewed-on: https://chromium-review.googlesource.com/443185Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43235}
-
- 15 Feb, 2017 1 commit
-
-
Michael Starzinger authored
This handles all arithmetic binary operations except addition during the early type-hint lowering (i.e. during graph construction). We still use static type information to potentially further reduce the speculative operations down to pure operations during the typed lowering phase. R=bmeurer@chromium.org Change-Id: I8b93fd7c46ec8e5b81234a49624d503520c3d082 Reviewed-on: https://chromium-review.googlesource.com/443105Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#43218}
-
- 09 Feb, 2017 1 commit
-
-
bmeurer authored
Since the empty string is canonical HeapObject now, we can use this fact to optimize - strict equality comparisons with the empty string to a simple ReferenceEqual operation, and - optimize ToBoolean to avoid instance type checks completely. Drive-by-fix: Allow InternalizedString for Type::HeapConstant in the type system. This is safe, since InternalizedStrings can be compared to other heap constants by reference (except for non-InternalizedStrings, which are excluded from the HeapConstant type). BUG=v8:5267 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2681273002 Cr-Commit-Position: refs/heads/master@{#43050}
-
- 01 Feb, 2017 2 commits
-
-
petermarshall authored
Review-Url: https://codereview.chromium.org/2666783007 Cr-Commit-Position: refs/heads/master@{#42847}
-
petermarshall authored
Review-Url: https://codereview.chromium.org/2662263002 Cr-Commit-Position: refs/heads/master@{#42836}
-
- 26 Jan, 2017 1 commit
-
-
bmeurer authored
We turn a JSCallFunction node for f.apply(receiver, arguments) into a JSCallForwardVarargs node, when the arguments refers to the arguments of the outermost optimized code object, i.e. not an inlined arguments, and the apply method refers to Function.prototype.apply, and there's no other user of arguments except in frame states. We also replace the arguments node in the graph with a marker for the Deoptimizer similar to Crankshaft to make sure we don't materialize unused arguments just for the sake of deoptimization. We plan to replace this with a saner EscapeAnalysis based solution soon. R=jarin@chromium.org BUG=v8:5267,v8:5726 Review-Url: https://codereview.chromium.org/2655233002 Cr-Commit-Position: refs/heads/master@{#42680}
-
- 18 Jan, 2017 1 commit
-
-
bmeurer authored
Lower JSLoadMessage and JSStoreMessage in JSTypedLowering to allow for optimizations across try-catch, try-finally, for-of, destructuring, etc. BUG=v8:5448 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2641843002 Cr-Commit-Position: refs/heads/master@{#42453}
-
- 09 Jan, 2017 1 commit
-
-
bmeurer authored
If one input to JSStrictEqual/JSNotStrictEqual is Unique (except InternalizedString) or the hole, then we can turn that into a direct pointer comparison, as such values are only equal to exactly the same unique value. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2611363002 Cr-Commit-Position: refs/heads/master@{#42122}
-