- 08 Aug, 2016 2 commits
-
-
bmeurer authored
This allows us to consume the type hints gathered by the CompareIC for the abstract equality and inequality operators. We need to distinguish Number and NumberOrOddball feedback now, as abstract equality doesn't truncate null and undefined to Number. R=epertoso@chromium.org BUG=v8:4583 Review-Url: https://codereview.chromium.org/2222983002 Cr-Commit-Position: refs/heads/master@{#38432}
-
bmeurer authored
Introduce a dedicated MaybeGrowFastElements simplified operator, which tries to grow a fast elements backing store for a given element that should be added to an array/object. Use that to lower a growing keyed store to a sequence of 1) check index is a valid array index, 2) check stored value, 3) maybe grow elements backing store (and deoptimize if it would normalize), and 4) store the actual element. The actual growing is done by two dedicated GrowFastDoubleElements and GrowFastSmiOrObjectElements builtins, which are very similar to the GrowArrayElementsStub that is used by Crankshaft. Drive-by-fix: Turn CopyFixedArray into CopyFastSmiOrObjectElements builtin, similar to the new growing builtins, so we don't need to inline the store+write barrier for the elements into all optimized code objects anymore. Also fix a bug in the OperationTyper for NumberSilenceNaN, which was triggered by this change. BUG=v8:5272 Review-Url: https://codereview.chromium.org/2227493002 Cr-Commit-Position: refs/heads/master@{#38418}
-
- 05 Aug, 2016 4 commits
-
-
bmeurer authored
This extends JSNativeContextSpecialization with support for stores to fast object/smi element backing stores that are marked as copy-on-write. In this case we first call the CopyFixedArray builtin to take a copy of the elements backing store, and then store the new elements back to the object, and finally perform the actual element store. R=epertoso@chromium.org BUG=v8:4470 Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6 Review-Url: https://codereview.chromium.org/2218703003 Cr-Original-Commit-Position: refs/heads/master@{#38370} Cr-Commit-Position: refs/heads/master@{#38392}
-
bmeurer authored
Revert of [turbofan] Add support for copy-on-write element stores. (patchset #2 id:20001 of https://codereview.chromium.org/2218703003/ ) Reason for revert: Breaks tree? Original issue's description: > [turbofan] Add support for copy-on-write element stores. > > This extends JSNativeContextSpecialization with support for stores to > fast object/smi element backing stores that are marked as copy-on-write. > In this case we first call the CopyFixedArray builtin to take a copy of > the elements backing store, and then store the new elements back to the > object, and finally perform the actual element store. > > R=epertoso@chromium.org > BUG=v8:4470 > > Committed: https://crrev.com/ac98ad22f049a59c48387f1bab1590f135d219c6 > Cr-Commit-Position: refs/heads/master@{#38370} TBR=epertoso@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4470 Review-Url: https://codereview.chromium.org/2220513002 Cr-Commit-Position: refs/heads/master@{#38376}
-
bmeurer authored
This extends JSNativeContextSpecialization with support for stores to fast object/smi element backing stores that are marked as copy-on-write. In this case we first call the CopyFixedArray builtin to take a copy of the elements backing store, and then store the new elements back to the object, and finally perform the actual element store. R=epertoso@chromium.org BUG=v8:4470 Review-Url: https://codereview.chromium.org/2218703003 Cr-Commit-Position: refs/heads/master@{#38370}
-
epertoso authored
It's just a refactoring to avoid introducing new floating controls in the SimplifiedLowering phase. R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2215183003 Cr-Commit-Position: refs/heads/master@{#38365}
-
- 03 Aug, 2016 3 commits
-
-
bmeurer authored
When we do a checked conversion from Tagged or Float64 to Int32, we used to always do a minus zero check, even if we already know that the input cannot be minus zero. Now we actually do the check only if we have evidence that the input might be minus zero. R=epertoso@chromium.org BUG=v8:4583 Review-Url: https://codereview.chromium.org/2202993005 Cr-Commit-Position: refs/heads/master@{#38308}
-
bmeurer authored
So far we treated SignedSmall and Signed32 feedback the same for number operations. However it would be beneficial to generate (a lot) less code if we only do a Smi check on the inputs instead of doing the full Smi + HeapNumber + conversion check that we need to do for Signed32 feedback. R=epertoso@chromium.org BUG=v8:4583 Review-Url: https://codereview.chromium.org/2207893002 Cr-Commit-Position: refs/heads/master@{#38290}
-
mstarzinger authored
This completely removes the ability from nodes to point directly to the frame state representing their eager bailout point. All nodes now either have zero or one frame state inputs. These frame states can by now be found via checkpoints in the graph. R=bmeurer@chromium.org BUG=v8:5021 Review-Url: https://codereview.chromium.org/2020323004 Cr-Commit-Position: refs/heads/master@{#38282}
-
- 02 Aug, 2016 1 commit
-
-
bmeurer authored
This adds support for lowering keyed access to JSTypedArray objects to element loads and stores instead of IC calls. There's still a lot of room for improvement, but the improvements can be done incrementally later. We add a dedicated UnsafePointerAdd operator, which sits in the effect chain, and does the (GC invisible) computation of addresses that are potentially inside HeapObjects. Also there's now a dedicated Retain operator, which ensures that we retain a certain tagged value, which is necessary to ensure that we keep a JSArrayBuffer alive as long as we might still potentially access elements in its backing store. R=epertoso@chromium.org Review-Url: https://codereview.chromium.org/2203693002 Cr-Commit-Position: refs/heads/master@{#38235}
-
- 30 Jul, 2016 1 commit
-
-
bmeurer authored
We have a similar optimization for unchecked integer modulus, which already boosted some asm.js use cases. Now this optimization is almost as effcient as Crankshafts known power of 2 right hand side optimization for modulus, but it can still deal with any rhs (except 0), and doesn't require the interpreter to also collect known power of two rhs feedback. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2200453002 Cr-Commit-Position: refs/heads/master@{#38187}
-
- 29 Jul, 2016 1 commit
-
-
bmeurer authored
So far we always create explicit control flow for map checks during JSNativeContextSpecialization, or in the monomorphic case we used a CheckIf combined with a map comparison. In either case we cannot currently effectively utilize the map check information during load elimination to optimize (polymorphic) map checks and elements kind transitions. With the introduction of CheckMaps, we can now start optimizing map checks in a more effective fashion. This CL doesn't change anything in that direction yet, but merely changes the fundamental mechanism. This also removes the stable map optimization from the Typer, where it was always a bit odd, and puts it into the typed lowering and the native context specialization instead. R=epertoso@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2196653002 Cr-Commit-Position: refs/heads/master@{#38166}
-
- 27 Jul, 2016 3 commits
-
-
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}
-
epertoso authored
This leads to a better handling of the Smi case when we introduce a checked truncation from a number or oddbal to a 32 bit word, which we were previously doing by concatenating a Smi to float64 conversion with a float64 to word32 truncation. BUG= Review-Url: https://codereview.chromium.org/2191503002 Cr-Commit-Position: refs/heads/master@{#38091}
-
bmeurer authored
Introduce the CheckString during native context specialization when we have string map feedback on a LOAD_IC/STORE_IC. The CheckString operator, just like its CheckNumber pendant, renames the input and assigns a proper type, which we will use soon to lower access operations on Strings, i.e. charCodeAt calls or keyed accesses. R=jarin@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2181943003 Cr-Commit-Position: refs/heads/master@{#38076}
-
- 20 Jul, 2016 2 commits
-
-
bmeurer authored
Revert of [turbofan] Introduce TruncateTaggedToBit operator for ToBoolean truncation. (patchset #2 id:20001 of https://codereview.chromium.org/2167593002/ ) Reason for revert: Breaks arm64 gc stress: https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/builds/1605 Original issue's description: > [turbofan] Introduce TruncateTaggedToBit operator for ToBoolean truncation. > > Add a dedicated simplified operator to inline the general case for the > ToBoolean conversion. In a follow up CL we will also use the ToBoolean > hints gathered by the baseline compiler. > > Committed: https://crrev.com/8c50b51ab3d21efcd2f6900d83962159f21e1590 > Cr-Commit-Position: refs/heads/master@{#37882} TBR=jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review-Url: https://codereview.chromium.org/2170433002 Cr-Commit-Position: refs/heads/master@{#37899}
-
bmeurer authored
Add a dedicated simplified operator to inline the general case for the ToBoolean conversion. In a follow up CL we will also use the ToBoolean hints gathered by the baseline compiler. Review-Url: https://codereview.chromium.org/2167593002 Cr-Commit-Position: refs/heads/master@{#37882}
-
- 19 Jul, 2016 1 commit
-
-
bmeurer authored
Instead of wriring the elements kind transitions into the control flow early on, we do instead put this marker into the effect chain, so that the elements transitions are visible to the LoadElimination and can thus be optimized properly there. This CL itself doesn't add any of those optimizations, but just adds the foundations to make them possible later. R=jarin@chromium.org BUG=v8:4930,v8:5141 Review-Url: https://codereview.chromium.org/2164573003 Cr-Commit-Position: refs/heads/master@{#37869}
-
- 18 Jul, 2016 2 commits
-
-
mvstanton authored
In int32 multiplication, if we have a positive integer as input, then we know we can't produce a -0 answer. The same is true if truncation is applied (x * y | 0). Without this information, we have to rather annoyingly check if the result of multiplication is 0, then OR the inputs to check for negativity, and possibly return -0. In TurboFan, we'll deopt in this case. BUG= Review-Url: https://codereview.chromium.org/2154073002 Cr-Commit-Position: refs/heads/master@{#37831}
-
bmeurer authored
So far TurboFan wasn't adding the deoptimization reasons for eager/soft deoptimization exits that can be used by either the DevTools profiler or the --trace-deopt flag. This adds basic support for deopt reasons on Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through the reasons to the code generation. Also moves the DeoptReason to it's own file (to resolve include cycles) and drops unused reasons. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2161543002 Cr-Commit-Position: refs/heads/master@{#37823}
-
- 16 Jul, 2016 1 commit
-
-
jarin authored
Delaying for merges caused branch cloning using dummy effect phi inputs, potentially splitting the effect chain at start. We still have to delay the creation for loops because we need to break cycles. BUG=chromium:628403 Review-Url: https://codereview.chromium.org/2159603002 Cr-Commit-Position: refs/heads/master@{#37808}
-
- 14 Jul, 2016 1 commit
-
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2141953002 Cr-Commit-Position: refs/heads/master@{#37764}
-
- 13 Jul, 2016 2 commits
-
-
bmeurer authored
Checked integer division and modulus can be done more efficiently if we know that the inputs are in Unsigned32 range. Drive-by-fix: Replace the TypeCheckKind on NodeInfo by a proper restriction type, and thread the feedback type through binary Number operations similar to what we do for their speculative versions. Also deal with Unsigned32 inputs for integer multiplication. R=jarin@chromium.org BUG=v8:4583,v8:5141 Review-Url: https://codereview.chromium.org/2149493002 Cr-Commit-Position: refs/heads/master@{#37703}
-
bmeurer authored
When the effect control linearizer tries to clone a branch, it accidentially connected regular Phis into the effect chain. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2146553006 Cr-Commit-Position: refs/heads/master@{#37698}
-
- 12 Jul, 2016 2 commits
-
-
epertoso authored
When trying to clone a branch, the ControlFlowOptimizer gave up as soon as it found a Phi/EffectPhi node that could not be placed directly below the IfTrue or IfFalse control paths. Moving the step in the EffectControlLinearizer phase, after the first schedule, works around the problem by looking at the successor blocks. BUG= Review-Url: https://codereview.chromium.org/2139593002 Cr-Commit-Position: refs/heads/master@{#37687}
-
bmeurer authored
The manual input trimming inside the EffectControlLinearizer is no longer necessary, since we have to do explicit graph trimming before running the MemoryOptimizer anyways these days. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2144603002 Cr-Commit-Position: refs/heads/master@{#37681}
-
- 11 Jul, 2016 1 commit
-
-
bmeurer authored
Consume Smi/Signed32 feedback for division and modulus and introduce appropriate checked operators. This is especially important for modulus where the Float64Mod operator is significantly slower than Int32Mod on most platforms. For division it's mostly important to propagate integerness, i.e. to avoid follow-up conversions between float and int32. Drive-by-fix: Use Int32Mod for the ModulusStub (and the bytecode handler) when the inputs are both Smi. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2138633002 Cr-Commit-Position: refs/heads/master@{#37621}
-
- 30 Jun, 2016 1 commit
-
-
bmeurer authored
This adds a new CheckIf operator and changes all direct uses of DeoptimizeIf and DeoptimizeUnless on the JavaScript level to use CheckIf (or one of the more concrete check operators) instead. This way we do not depend on particular frame states, but the effect/control linearizer will assign an appropriate frame state instead. R=jarin@chromium.org BUG=v8:5141 Review-Url: https://codereview.chromium.org/2115513002 Cr-Commit-Position: refs/heads/master@{#37423}
-
- 29 Jun, 2016 1 commit
-
-
bmeurer authored
The only real use case left for TypeGuard was the renaming inside the LoadElimination, but this case only occurs in dead code (guarded by a previous Check), so it's not relevant, and we can drop the TypeGuard operator completely. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2108793003 Cr-Commit-Position: refs/heads/master@{#37361}
-
- 28 Jun, 2016 1 commit
-
-
bmeurer authored
We use CheckNumber to guard values as being proper numbers, i.e. if the input value is anything but a Number, we deoptimize. This follows the existing effect/control linearization magic that we already use for the other checks. R=jarin@chromium.org BUG=v8:5141 Review-Url: https://codereview.chromium.org/2109623002 Cr-Commit-Position: refs/heads/master@{#37329}
-
- 21 Jun, 2016 1 commit
-
-
bmeurer authored
Add control dependencies to Projection and Int32Add/SubWithOverflow operators, to prevent the scheduler from moving the Projection nodes into the wrong place. This way the instruction selection can combine the Int32Add/SubWithOverflow operations with the DeoptimizeIf and/or DeoptimizeUnless nodes. This needs new operators CheckedInt32Add and CheckedInt32Sub so that we can delay the actual lowering until the effect/control linearizer. This also makes CheckIf operator obsolete, so we can drop it. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2082993002 Cr-Commit-Position: refs/heads/master@{#37148}
-
- 20 Jun, 2016 3 commits
-
-
bmeurer authored
These are used to check for Smi or HeapObject, and we use them appropriately in JSNativeContextSpecialization, so we don't need to introduce dependencies on concrete control flow and/or concrete frame states. They will be optimized by a proper check elimination reducer, which will be added in a separate CL. R=jarin@chromium.org BUG=v8:4470 Review-Url: https://codereview.chromium.org/2082523002 Cr-Commit-Position: refs/heads/master@{#37096}
-
machenbach authored
Revert of [turbofan] Introduce CheckUnless. (patchset #1 id:1 of https://codereview.chromium.org/2080113002/ ) Reason for revert: [Sheriff] Speculative revert: Seems to lead to devtools crashes: https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Win/builds/5259 Original issue's description: > [turbofan] Introduce CheckUnless. > > Similarly to CheckIf, CheckUnless is a deoptimization without a specific > frame state. A frame state is assigned during effect-control linearization > (and CheckUnless is turned into DeoptimizeUnless). > > At the moment, the new operator is only used at one place in native context > specialization, but we should use it everywhere. The advantage of > CHeckUnless is that it avoids non-truncating uses of values by frame > states. This particular change is aimed at Octane's crypto, where this > enables to turn one NumberMultiply into Int32Mul, and thus improve > the score by more than 10% (it also needs minus zero truncation and > typing to be improved, but those CLs are already in flight). > > BUG=v8:4470 > R=bmeurer@chromium.org > > Committed: https://crrev.com/85fde59d538e0dcaf461108086c2f7cf904f567a > Cr-Commit-Position: refs/heads/master@{#37085} TBR=bmeurer@chromium.org,jarin@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4470 Review-Url: https://codereview.chromium.org/2078333002 Cr-Commit-Position: refs/heads/master@{#37090}
-
jarin authored
Similarly to CheckIf, CheckUnless is a deoptimization without a specific frame state. A frame state is assigned during effect-control linearization (and CheckUnless is turned into DeoptimizeUnless). At the moment, the new operator is only used at one place in native context specialization, but we should use it everywhere. The advantage of CHeckUnless is that it avoids non-truncating uses of values by frame states. This particular change is aimed at Octane's crypto, where this enables to turn one NumberMultiply into Int32Mul, and thus improve the score by more than 10% (it also needs minus zero truncation and typing to be improved, but those CLs are already in flight). BUG=v8:4470 R=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2080113002 Cr-Commit-Position: refs/heads/master@{#37085}
-
- 15 Jun, 2016 3 commits
-
-
bmeurer authored
This CheckBounds simplified operator is similar to the HBoundsCheck in Crankshaft, and is hooked up to the new type feedback support in the SimplifiedLowering. We use it to check the index bounds for keyed property accesses. Note to perf sheriffs: This will tank quite a few benchmarks, as the operator makes some redundant branch elimination ineffective for certain patterns of keyed accesses. This does require more serious redundancy elimination, which we will do in a separate CL. So ignore any regressions from this CL, we know there will be a few. R=jarin@chromium.org BUG=v8:4470,v8:5100 Committed: https://crrev.com/85e5567dae66a918500ae94c5568221137a0f5d4 Review-Url: https://codereview.chromium.org/2035893004 Cr-Original-Commit-Position: refs/heads/master@{#36947} Cr-Commit-Position: refs/heads/master@{#37003}
-
bmeurer authored
These simplified operators are used to perform the hole checks when loading elements from a holey array. Depending on the CheckHoleMode, they either return the hole as undefined or some NaN, or deoptimize if the value is the hole or the hole NaN. R=jarin@chromium.org Review-Url: https://codereview.chromium.org/2066223002 Cr-Commit-Position: refs/heads/master@{#37001}
-
jarin authored
Review-Url: https://codereview.chromium.org/2063373003 Cr-Commit-Position: refs/heads/master@{#36996}
-
- 14 Jun, 2016 2 commits
-
-
vogelheim authored
Revert of [turbofan] Introduce a dedicated CheckBounds operator. (patchset #5 id:80001 of https://codereview.chromium.org/2035893004/ ) Reason for revert: Speculative revert since V8 roll is blocked. Buildbot: https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_rel_ng/builds/228171 Example log: https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_chromeos_rel_ng/builds/228171/steps/browser_tests%20%28with%20patch%29%20on%20Ubuntu-12.04/logs/CreateNewFolder_FileManagerBrowserTest.Test_0 Failing assert: # # Fatal error in ../../v8/src/compiler/node.cc, line 63 # Node::New() Error: #202:DeoptimizeUnless[1] is nullptr # (I take it that's a rather generic assert in TF, hence the revert is somewhat sepculative.) Original issue's description: > [turbofan] Introduce a dedicated CheckBounds operator. > > This CheckBounds simplified operator is similar to the HBoundsCheck in > Crankshaft, and is hooked up to the new type feedback support in the > SimplifiedLowering. We use it to check the index bounds for keyed > property accesses. > > Note to perf sheriffs: This will tank quite a few benchmarks, as the > operator makes some redundant branch elimination ineffective for > certain patterns of keyed accesses. This does require more serious > redundancy elimination, which we will do in a separate CL. So ignore > any regressions from this CL, we know there will be a few. > > R=jarin@chromium.org > BUG=v8:4470,v8:5100 > > Committed: https://crrev.com/85e5567dae66a918500ae94c5568221137a0f5d4 > Cr-Commit-Position: refs/heads/master@{#36947} TBR=jarin@chromium.org,bmeurer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:4470,v8:5100 Review-Url: https://codereview.chromium.org/2064163002 Cr-Commit-Position: refs/heads/master@{#36975}
-
bmeurer authored
This CheckBounds simplified operator is similar to the HBoundsCheck in Crankshaft, and is hooked up to the new type feedback support in the SimplifiedLowering. We use it to check the index bounds for keyed property accesses. Note to perf sheriffs: This will tank quite a few benchmarks, as the operator makes some redundant branch elimination ineffective for certain patterns of keyed accesses. This does require more serious redundancy elimination, which we will do in a separate CL. So ignore any regressions from this CL, we know there will be a few. R=jarin@chromium.org BUG=v8:4470,v8:5100 Review-Url: https://codereview.chromium.org/2035893004 Cr-Commit-Position: refs/heads/master@{#36947}
-
- 10 Jun, 2016 1 commit
-
-
jarin authored
TBR=bmeurer@chromium.org Review-Url: https://codereview.chromium.org/2057063002 Cr-Commit-Position: refs/heads/master@{#36886}
-