- 07 Oct, 2018 1 commit
-
-
Benedikt Meurer authored
As identified in the web-tooling-benchmark, there are specific code patterns involving array indexed property accesses and subsequent comparisons of those indices that lead to repeated Smi checks in the optimized code, which in turn leads to high register pressure and generally bad register allocation. An example of this pattern is code like this: ```js function f(a, n) { const i = a[n]; if (n >= 1) return i; } ``` The `a[n]` property access introduces a CheckBounds on `n`, which later lowers to a `CheckedTaggedToInt32[dont-check-minus-zero]`, however the `n >= 1` comparison has collected `SignedSmall` feedback and so it introduces a `CheckedTaggedToTaggedSigned` operation. This second Smi check is redundant and cannot easily be combined with the earlier tagged->int32 conversion, since that also deals with heap numbers and even truncates -0 to 0. So we teach the RedundancyElimination to look at the inputs of these speculative number comparisons and if there's a leading bounds check on either of these inputs, we change the input to the result of the bounds check. This avoids the redundant Smi checks later and generally allows the SimplifiedLowering to do a significantly better job on the number comparisons. We only do this in case of SignedSmall feedback and only for inputs that are not already known to be in UnsignedSmall range, to avoid doing too many (unnecessary) expensive lookups during RedundancyElimination. All of this is safe despite the fact that CheckBounds truncates -0 to 0, since the regular number comparisons in JavaScript identify 0 and -0 (unlike Object.is()). This also adds appropriate tests, especially for the interesting cases where -0 is used only after the code was optimized. Bug: v8:6936, v8:7094 Change-Id: Ie37114fb6192e941ae1a4f0bfe00e9c0a8305c07 Reviewed-on: https://chromium-review.googlesource.com/c/1246181Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56428}
-
- 20 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
Remove the NumberConstant right hand side limitation for the speculative number operation optimization, and extend the logic to also deal with SpeculativeToNumber, which is common when dealing with postfix increment and array operations. Also add appropriate tests for all the relevant cases, specifically we mjsunit tests to increase the general coverage for the various cases here (in addition to dedicated unittests). Bug: v8:8015 Change-Id: I8c92f98490c63b07eb19686efd404322979e57c4 Reviewed-on: https://chromium-review.googlesource.com/1235919Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56072}
-
- 19 Sep, 2018 1 commit
-
-
Benedikt Meurer authored
Make the RedundancyElimination handle all simplified operators that are listed in the SIMPLIFIED_CHECKED_OP_LIST, and fix a couple of bugs and oversights in the code. This also adds a lot of test coverage for all the cases that we care about in RedundancyElimination (with respect to Check/Checked simplified operators). Bug: v8:8015 Change-Id: I57d29113389841b09abcd013313bf5dd1c67735f Reviewed-on: https://chromium-review.googlesource.com/1233655Reviewed-by:
Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#56032}
-
- 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}
-
- 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}
-
- 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}
-
- 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}
-