- 02 Jan, 2017 1 commit
-
-
bmeurer authored
Add machinery to Ignition and TurboFan to collect and consume InternalizedString feedback for abstract and strict equality comparisons. Here we can turn the comparison into a simple pointer equality check. R=jarin@chromium.org BUG=v8:5786 Review-Url: https://codereview.chromium.org/2609013002 Cr-Commit-Position: refs/heads/master@{#42008}
-
- 13 Dec, 2016 1 commit
-
-
tebbi authored
R=jarin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2568423003 Cr-Commit-Position: refs/heads/master@{#41681}
-
- 24 Nov, 2016 1 commit
-
-
jarin authored
This has two parts: - in redundancy elimination, if we see addition with left hand side that was bounds-checked, we reconnect the lhs to the bounds check if it has better type. - in representation inference, eliminate overflow checks if the input types guarantee no overflow. Review-Url: https://codereview.chromium.org/2527083002 Cr-Commit-Position: refs/heads/master@{#41260}
-
- 23 Sep, 2016 1 commit
-
-
Benedikt Meurer authored
Rename the high-level operators CheckTaggedSigned to CheckSmi and CheckTaggedPointer to CheckHeapObject, to better match the naming convention (i.e. ObjectIsSmi and CheckSmi, ObjectIsString and CheckString, etc.). For lowering CheckSmi, always report TaggedSigned representation and let the RepresentationChanger come up with a reasonable conversion from whatever input representation to TaggedSigned. This way we no longer insert the useless ChangeSomethingToTagged and then Smi check the result sequences, i.e. mostly reduces the amount of useless code being generated. But we also observe a few performance improvements on some crypto benchmarks. This would enable us to avoid the Smi canonicalization when going from Float64 to Tagged completely and thus match the representation selection of Crankshaft in many areas (which might reduce the amount of polymorphism until we fix our object model). A follow-up CL will do the same for CheckHeapObject. BUG=v8:5267 R=jarin@chromium.org Review URL: https://codereview.chromium.org/2362173003 . Cr-Commit-Position: refs/heads/master@{#39654}
-
- 03 Aug, 2016 1 commit
-
-
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}
-
- 27 Jul, 2016 1 commit
-
-
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}
-
- 14 Jul, 2016 1 commit
-
-
mvstanton authored
BUG= Review-Url: https://codereview.chromium.org/2141953002 Cr-Commit-Position: refs/heads/master@{#37764}
-
- 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
A pointer comparison on the effect path states is not sufficient to guarantee termination; we really need to check the actual nodes to make sure we terminate properly, similar to what BranchElimination does. R=jarin@chromium.org BUG=v8:5161 Review-Url: https://codereview.chromium.org/2112463002 Cr-Commit-Position: refs/heads/master@{#37389}
-
- 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}
-
- 23 Jun, 2016 1 commit
-
-
bmeurer authored
The redundancy elimination is currently a graph reducer that tries to combine redundant checks in the effect chain. It does this by propagating the checks that happened along effect paths, which is pretty similar to what the BranchElimination does on the control chain. We run this reducer together with the other optimizations right after the representation selection. An upcoming CL will extend the redundancy elimination to also eliminate redundant loads (and eventually map checks). R=jarin@chromium.org BUG=v8:5141 Review-Url: https://codereview.chromium.org/2091503003 Cr-Commit-Position: refs/heads/master@{#37208}
-