- 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}
-
- 04 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
The Object.is builtin provides an entry point to the abstract operation SameValue, which properly distinguishes -0 and 0, and also identifies NaNs. Most of the time you don't need these, but rather just regular strict equality, but when you do, Object.is(o, -0) is the most readable way to check for minus zero. This is for example used in Node.js by formatNumber to properly print -0 for negative zero. However since the builtin thus far implemented as C++ builtin and TurboFan didn't know anything about it, Node.js considering to go with a more performant, less readable version (which also makes assumptions about the input value) in https://github.com/nodejs/node/pull/15726 until the performance of Object.is will be on par (so hopefully we can go back to Object.is in Node 9). This CL ports the baseline implementation of Object.is to CSA, which is pretty straight-forward since SameValue is already available in CodeStubAssembler, and inlines a few interesting cases into TurboFan, i.e. comparing same SSA node, and checking for -0 and NaN explicitly. On the micro-benchmarks we go from testNumberIsMinusZero: 1000 ms. testObjectIsMinusZero: 929 ms. testObjectIsNaN: 954 ms. testObjectIsSame: 793 ms. testStrictEqualSame: 104 ms. to testNumberIsMinusZero: 89 ms. testObjectIsMinusZero: 88 ms. testObjectIsNaN: 88 ms. testObjectIsSame: 86 ms. testStrictEqualSame: 105 ms. which is a nice 10x to 11x improvement and brings Object.is on par with strict equality for most cases. Drive-by-fix: Also refactor and optimize the SameValue check in the CodeStubAssembler to avoid code bloat (by not inlining StrictEqual into every user of SameValue, and also avoiding useless checks). Bug: v8:6882 Change-Id: Ibffd8c36511f219fcce0d89ed4e1073f5d6c6344 Reviewed-on: https://chromium-review.googlesource.com/700254Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48275}
-
- 02 Oct, 2017 1 commit
-
-
Benedikt Meurer authored
The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and as far as I can tell only definitely side-effect free) way to check whether an arbitrary object is a TypedArray - either generally TypedArray or a specific one like Uint8Array. Using the getter is thus emerging as the general pattern to detect TypedArrays, even Node.js now adapted it starting with https://github.com/nodejs/node/pull/15663 for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js now. The getter returns either the string with the TypedArray subclass name (i.e. "Uint8Array") or undefined if the receiver is not a TypedArray. This can be implemented with a simple elements kind dispatch, instead of checking the instance type and then loading the class name from the constructor, which requires a loop walking up the transition tree. This CL ports the builtin to CSA and TurboFan, and changes the logic to a simple elements kind check. On the micro-benchmark mentioned in the referenced bug, the time goes from testIsArrayBufferView: 565 ms. testIsTypedArray: 2403 ms. testIsUint8Array: 3847 ms. to testIsArrayBufferView: 566 ms. testIsTypedArray: 965 ms. testIsUint8Array: 965 ms. which presents an up to 4x improvement. Bug: v8:6874 Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611 Reviewed-on: https://chromium-review.googlesource.com/695021Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48254}
-
- 30 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
This improves performance of ArrayBuffer.isView by roughly 2.5x itself, and enables optimizations across ArrayBuffer.isView calls, i.e. map checks can be eliminated across. This was discovered in a related Node pull request (https://github.com/nodejs/node/pull/15663). Bug: v8:6868 Change-Id: I1d56ec385f8daa0e1d44d3bc4d6c9a5558ba4522 Reviewed-on: https://chromium-review.googlesource.com/691660Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48247}
-
- 05 Sep, 2017 1 commit
-
-
Adam Klein authored
Change-Id: I891ff57b7a3a47e3371269b123705cdf6391499b Reviewed-on: https://chromium-review.googlesource.com/648513Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#47830}
-
- 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}
-
- 14 Jul, 2017 1 commit
-
-
Benedikt Meurer authored
This CL inlines the following builtins into TurboFan - %MapIteratorPrototype%.next - %SetIteratorPrototype%.next following the design that we are using for Array iteration already (different instance types for the different kinds of iterators). Details can be found in the relevant design document at: https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8 The key to great performance here is to ensure that the inlined code allows escape analysis and scalar replacement of aggregates to remove the allocations for the iterator itself as well as the iterator results and potential key/value arrays in the simple case of a for-of loop (and by extension also in other constructs that reduce to for-of loops internally), i.e.: const s = new Set; // ... do something with s for (const x of s) { // ... } Here the for-of loop shouldn't perform any allocations of helper objects. Drive-by-fix: Replace the ExistsJSMapWithness in JSBuiltinReducer with a more general HasInstanceTypeWitness, similar to what's in JSCallReducer. Also migrate the {Map,Set}.prototype.size getter inlining to the JSBuiltinReducer, so that everything is in a single place. R=jgruber@chromium.org Bug: v8:6344, v8:6571, chromium:740122 Change-Id: I09cb506fe26ed3e10d7dcb2f95ec4415e639582d Reviewed-on: https://chromium-review.googlesource.com/570159Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#46655}
-
- 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}
-
- 10 Jul, 2017 1 commit
-
-
Jaroslav Sevcik authored
This introduces a new builtin (MapLookupHashIndex) and uses it in Turbofan to compute Map.p.get and Map.p.has. I have also refactored the existing CSA builtins for Map.p.get and Map.p.has to use the new builtin under the hood. The code for the lookup has been also improved. - Specialized lookups for smis, strings, heap numbers and everything else. - the advantage is that we can use fast equalities for the lookup. - strings can likely be optimized further if we care about the internalized string fast case. - Instead of a call to runtime to get the hash code, we now call C directly. In the Turbofan implementation itself, there are no special optimizations yet. The next step is to teach load elimination to reuse the indexes from previous calls of MapLookupHashIndex. BUG=v8:6410 Change-Id: I0b1a70493eb031d444e51002f6b2cc1f30ea2b68 Reviewed-on: https://chromium-review.googlesource.com/560169Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#46510}
-
- 26 Jun, 2017 1 commit
-
-
Jaroslav Sevcik authored
This is mainly to enable optimization of case-insensitive maps, where we see the pattern if (m.has(key.toLowerCase())) { return m.get(key.toLowerCase()) } ... Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: I8c78a185401c51e8a53ae2932a158eaafa169495 Reviewed-on: https://chromium-review.googlesource.com/547057 Commit-Queue: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46206}
-
- 02 Jun, 2017 1 commit
-
-
bmeurer authored
When the input to Function.prototype.bind is a known function, we can inline the allocation of the JSBoundFunction into TurboFan, which provides a 2x speed-up for several hot functions in Node streams (as discovered by Matteo Collina). One of example of this can be found in https://github.com/nodejs/node/pull/13322, which can be optimized and made more readable using bind instead of closures. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2916063002 Cr-Commit-Position: refs/heads/master@{#45679}
-
- 10 May, 2017 1 commit
-
-
bmeurer authored
For small arrays, it's way faster to just move the elements instead of doing the fairly complex and heavy-weight left-trimming. Crankshaft has had this optimization for small arrays already; this CL more or less ports this functionality to TurboFan, which yields a 4x speed-up when using shift on small arrays (with up to 16 elements). This should recover some of the regressions reported in the Node.js issues https://github.com/nodejs/node/issues/12657 and discovered for the syncthrough module using https://github.com/mcollina/syncthrough/blob/master/benchmarks/basic.js as benchmark. R=jarin@chromium.org BUG=v8:6376 Review-Url: https://codereview.chromium.org/2874453002 Cr-Commit-Position: refs/heads/master@{#45216}
-
- 20 Mar, 2017 1 commit
-
-
bmeurer authored
When we hit a call to String.prototype.concat builtin, where we can infer that the receiver is a String and there's exactly one parameter, which is of type PlainPrimitive, then we can reduce that to a call to the StringAddStub instead, optionally converting the non-String - but PlainPrimitive - parameter to a String. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2758383002 Cr-Commit-Position: refs/heads/master@{#43957}
-
- 27 Feb, 2017 1 commit
-
-
bmeurer authored
Inline the Array.isArray builtin during typed lowering, which generates ideal code for the common case (non-JSProxy arg), and use the existing %ArrayIsArray runtime function for the JSProxy case just like in baseline. BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2719023002 Cr-Commit-Position: refs/heads/master@{#43453}
-
- 26 Jan, 2017 1 commit
-
-
cbruni authored
Review-Url: https://codereview.chromium.org/2638393002 Cr-Commit-Position: refs/heads/master@{#42695}
-
- 13 Jan, 2017 3 commits
-
-
cbruni authored
In the ideal case, this will speed up Object.create(null) by ~10x. Drive-by-fix: Spread usage of new IsSpecialReceiverMap() and IsSpecialReceiverInstanceType(InstanceType) helpers. BUG=v8:5788 Review-Url: https://codereview.chromium.org/2622723003 Cr-Commit-Position: refs/heads/master@{#42336}
-
cbruni authored
Revert of [compiler] Support Object.create(null) inlining in TF (patchset #5 id:80001 of https://codereview.chromium.org/2622723003/ ) Reason for revert: Breaks buildbot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20avx2/builds/13399/steps/Benchmarks/logs/stdio Original issue's description: > [compiler] Support Object.create(null) inlining in TF > > In the ideal case, this will speed up Object.create(null) by ~10x. > > Drive-by-fix: Spread usage of new IsSpecialReceiverMap() and > IsSpecialReceiverInstanceType(InstanceType) helpers. > > BUG=v8:5788 > > Review-Url: https://codereview.chromium.org/2622723003 > Cr-Commit-Position: refs/heads/master@{#42321} > Committed: https://chromium.googlesource.com/v8/v8/+/ff7063c7d5d8ad8eafcce3da59e65d7fe2b4f915 TBR=jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5788 Review-Url: https://codereview.chromium.org/2636493003 Cr-Commit-Position: refs/heads/master@{#42326}
-
cbruni authored
In the ideal case, this will speed up Object.create(null) by ~10x. Drive-by-fix: Spread usage of new IsSpecialReceiverMap() and IsSpecialReceiverInstanceType(InstanceType) helpers. BUG=v8:5788 Review-Url: https://codereview.chromium.org/2622723003 Cr-Commit-Position: refs/heads/master@{#42321}
-
- 03 Jan, 2017 1 commit
-
-
bmeurer authored
Call the %DateCurrentTime runtime function directly instead, which is cheaper than calling the C++ builtin. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2612513003 Cr-Commit-Position: refs/heads/master@{#42028}
-
- 29 Nov, 2016 1 commit
-
-
bmeurer authored
For bound functions on the right-hand side of instanceof we can constant-fold to the actual [[BoundTargetFunction]], actually instance OrdinaryHasInstance. Move the Function.prototype[@@hasInstance] reduction up to the JSCallReducer to allow this optimization to become effective (and also enable other optimizations). BUG=v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2537763002 Cr-Commit-Position: refs/heads/master@{#41352}
-
- 18 Nov, 2016 1 commit
-
-
bmeurer authored
This is the TurboFan counterpart of http://crrev.com/2504263004, but it is a bit more involved, since in TurboFan we always inline the appropriate call to the @@hasInstance handler, and by that we can optimize a lot more patterns of instanceof than Crankshaft, and even yield fast instanceof for custom @@hasInstance handlers (which we can now properly inline as well). Also we now properly optimize Function.prototype[@@hasInstance], even if the right hand side of an instanceof doesn't have the Function.prototype as its direct prototype. For the baseline case, we still rely on the global protector cell, but we can address that in a follow-up as well, and make it more robust in general. TEST=mjsunit/compiler/instanceof BUG=v8:5640 R=yangguo@chromium.org Review-Url: https://codereview.chromium.org/2511223003 Cr-Commit-Position: refs/heads/master@{#41092}
-
- 14 Nov, 2016 1 commit
-
-
caitp authored
Adds a protector cell to prevent inlining (which will likely lead to deopt loops) when a JSArrayIterator's array transitions from a fast JSArray to a slow JSArray (such as, when the array is touched during iteration in a way which triggers a map transition). Also adds TODO comments relating to the spec update proposed by Dan at https://github.com/tc39/ecma262/pull/724 BUG=v8:5388 R=bmeurer@chromium.org, mstarzinger@chromium.org TBR=hpayer@chromium.org, ulan@chromium.org Review-Url: https://codereview.chromium.org/2484003002 Cr-Commit-Position: refs/heads/master@{#40970}
-
- 03 Nov, 2016 1 commit
-
-
franzih authored
Use HeapConstant for string_iterator_map rather than loading it manually. This avoids unnecessary map checks. BUG= v8:3822,v8:5267 Review-Url: https://codereview.chromium.org/2479563003 Cr-Commit-Position: refs/heads/master@{#40741}
-
- 18 Oct, 2016 1 commit
-
-
jwolfe authored
BUG=v8:5388 Review-Url: https://codereview.chromium.org/2422383002 Cr-Commit-Position: refs/heads/master@{#40406}
-
- 17 Oct, 2016 1 commit
-
-
jochen authored
R=machenbach@chromium.org,titzer@chromium.org,bmeurer@chromium.org,jgruber@chromium.org BUG= CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe Review-Url: https://codereview.chromium.org/2416243002 Cr-Commit-Position: refs/heads/master@{#40350}
-
- 05 Oct, 2016 3 commits
-
-
caitp authored
Reland https://codereview.chromium.org/2373983004/, reverted in 4e5a4d93. Reason: CL is not responsible for Win32 Debug failures (see https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/5031) ------------------------------------------------------------------------------ Implement the logic for StringIterator.prototype.next in the JSBuiltinReducer in order to allow inlining when the receiver is a JS_STRING_ITERATOR_TYPE map, built ontop of the SimplifiedOperators StringCharCodeAt and the newly added StringFromCodePoint. Also introduces a new StringFromCodePoint simplified op which may be useful for other String builtins, such as String.fromCodePoint() BUG=v8:5388 TBR=bmeurer@chromium.org, mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2394823003 Cr-Commit-Position: refs/heads/master@{#40008}
-
machenbach authored
Revert of [turbofan] inline %StringIteratorPrototype%.next in JSBuiltinReducer. (patchset #12 id:210001 of https://codereview.chromium.org/2373983004/ ) Reason for revert: [Sheriff] Speculative revert for win dbg: https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/5029 Or we have an infra problem. Manual build before seems fine: https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/5030 Original issue's description: > [turbofan] inline %StringIteratorPrototype%.next in JSBuiltinReducer. > > Implement the logic for StringIterator.prototype.next in the JSBuiltinReducer in order to allow inlining when the receiver is a JS_STRING_ITERATOR_TYPE map, built ontop of the SimplifiedOperators StringCharCodeAt and the newly added StringFromCodePoint. > > Also introduces a new StringFromCodePoint simplified op which may be useful for other String builtins, such as String.fromCodePoint() > > BUG=v8:5388 > R=bmeurer@chromium.org, mstarzinger@chromium.org > > Committed: https://crrev.com/aed32e0f22353527993de8bceaf246fc744558f5 > Cr-Commit-Position: refs/heads/master@{#39994} TBR=bmeurer@chromium.org,mvstanton@chromium.org,caitp@igalia.com # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5388 Review-Url: https://codereview.chromium.org/2397753003 Cr-Commit-Position: refs/heads/master@{#39995}
-
caitp authored
Implement the logic for StringIterator.prototype.next in the JSBuiltinReducer in order to allow inlining when the receiver is a JS_STRING_ITERATOR_TYPE map, built ontop of the SimplifiedOperators StringCharCodeAt and the newly added StringFromCodePoint. Also introduces a new StringFromCodePoint simplified op which may be useful for other String builtins, such as String.fromCodePoint() BUG=v8:5388 R=bmeurer@chromium.org, mstarzinger@chromium.org Review-Url: https://codereview.chromium.org/2373983004 Cr-Commit-Position: refs/heads/master@{#39994}
-
- 07 Sep, 2016 1 commit
-
-
bmeurer authored
Migrate the isNaN, isFinite, Number.isFinite, Number.isInteger, Number.isSafeInteger and Number.isNaN predicates to TurboFan builtins and make them optimizable (for certain input types) in JavaScript callees being optimized by TurboFan. That means both the baseline and the optimized version is now always at maximum, consistent performance. Especially TurboFan suffered from poor baseline (and optimized) performance because it cannot play the same weird tricks that Crankshaft plays for %_IsSmi. This also adds a bunch of new tests to properly cover the use of the Harmony predicates in optimized code. R=franzih@chromium.org BUG=v8:5049,v8:5267 Review-Url: https://codereview.chromium.org/2313073002 Cr-Commit-Position: refs/heads/master@{#39242}
-
- 29 Aug, 2016 2 commits
-
-
bmeurer authored
Infer exact types for the various Date getter builtins, and also inline the Date.prototype.getTime() builtin, which just returns the Date value and thus doesn't need to check the cache stamp. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2285213002 Cr-Commit-Position: refs/heads/master@{#38973}
-
bmeurer authored
For asm.js we now have a dedicated AsmTyper, that uses it's own type system (which is tailored towards asm.js), and so we don't need the special asm.js types anymore in the TypeCache. This also moves the TypeCache into the src/compiler directory, because it doesn't make sense to use outside anyways. TBR=ahaas@chromium.org R=jarin@chromium.org BUG=v8:5267 Review-Url: https://codereview.chromium.org/2289573002 Cr-Commit-Position: refs/heads/master@{#38964}
-
- 12 Aug, 2016 1 commit
-
-
bmeurer authored
This adds a very first version of inlined Array.prototype.push into TurboFan optimized code. The current inlined version has a potential deopt loop, but it's unlikely that we hit it currently (Crankshaft suffers from an even worse problem). Once we have a way to learn from deopts we can fix this deopt loops. It's also probably overly defensive in when it's safe to inline the call to Array.prototype.push, but we can always extend that later once we have sufficient trust in the implementation and see an actual need to extend it. BUG=v8:2229,v8:3952,v8:5267 R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2245533003 Cr-Commit-Position: refs/heads/master@{#38603}
-
- 11 Aug, 2016 1 commit
-
-
bmeurer authored
This adds a very first version of inlined Array.prototype.pop into TurboFan optimized code. We currently limit the inlining to fast object or smi elements, until the unclear situation around hole NaNs is resolved and we have a clear semantics inside the compiler. It's also probably overly defensive in when it's safe to inline the call to Array.prototype.pop, but we can always extend that later once we have sufficient trust in the implementation and see an actual need to extend it. BUG=v8:2229,v8:3952,v8:5267 R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2239703002 Cr-Commit-Position: refs/heads/master@{#38578}
-
- 01 Aug, 2016 1 commit
-
-
bmeurer authored
This adds initial support to inline a couple of the ArrayBuffer view accessors like %TypeArray%.prototype.length and. DataView.prototype.byteLength. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2199753002 Cr-Commit-Position: refs/heads/master@{#38200}
-
- 27 Jul, 2016 1 commit
-
-
bmeurer authored
Introduce an appropriate StringCharCodeAt simplified operator and use that to optimize the String.prototype.charCodeAt/.charAt builtins. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2180373005 Cr-Commit-Position: refs/heads/master@{#38106}
-
- 05 Jul, 2016 1 commit
-
-
bmeurer authored
The Number.parseInt (and therefore the parseInt function on the global object) are often used instead of Math.floor or just plain int32 truncation, and we can easily recognize those cases and provide a fast path in TurboFan. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2125583002 Cr-Commit-Position: refs/heads/master@{#37518}
-
- 01 Jul, 2016 1 commit
-
-
bmeurer authored
Import fdlibm versions of acos, acosh, asin and asinh, which are more precise and produce the same result across platforms (we were using libm versions for asin and acos so far, where both speed and precision depended on the operating system so far). Introduce appropriate TurboFan operators for these functions and use them both for inlining and for the generic builtin. Also migrate the Math.imul and Math.fround builtins to TurboFan builtins to ensure that their behavior is always exactly the same as the inlined TurboFan version (i.e. C++ truncation semantics for double to float don't necessarily meet the JavaScript semantics). For completeness, also migrate Math.sign, which can even get some nice love in TurboFan. Drive-by-fix: Some alpha-sorting on the Math related functions, and cleanup the list of Math intrinsics that we have to export via the native context currently. BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172 TBR=rossberg@chromium.org R=franzih@chromium.org Review-Url: https://codereview.chromium.org/2116753002 Cr-Commit-Position: refs/heads/master@{#37476}
-
- 30 Jun, 2016 1 commit
-
-
mvstanton authored
BUG=v8:5086 Review-Url: https://codereview.chromium.org/2083573002 Cr-Commit-Position: refs/heads/master@{#37424}
-
- 28 Jun, 2016 2 commits
-
-
bmeurer authored
Introduce a new machine operator Float64Pow that for now is backed by the existing MathPowStub to start the unification of Math.pow, and at the same time address the main performance issue that TurboFan still has with the imaging-darkroom benchmark in Kraken. Also migrate the Math.pow builtin itself to a TurboFan builtin and remove a few hundred lines of hand-written platform code for special handling of the fullcodegen Math.pow version. BUG=v8:3599,v8:5086,v8:5157 Review-Url: https://codereview.chromium.org/2103733003 Cr-Commit-Position: refs/heads/master@{#37323}
-
bmeurer authored
Add NumberAbs operator to implement an inline version of Math.abs, that can be optimized and eliminated. We don't use any speculation here, but for now stick to the information we can infer (this way we avoid the inherent deopt loops that Crankshaft has around Math.abs). CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel R=jarin@chromium.org BUG=v8:5086 Review-Url: https://codereview.chromium.org/2096403002 Cr-Commit-Position: refs/heads/master@{#37306}
-