- 10 Aug, 2017 1 commit
-
-
Michael Starzinger authored
This is in preparation to the removal of the FullCodeGenerator, we no longer need the ability to stress the underlying implementation. R=rmcilroy@chromium.org BUG=v8:6409 Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng Change-Id: Iad3177d6de4a68b57c12a770b6e85ed7a9710254 Reviewed-on: https://chromium-review.googlesource.com/584747Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#47276}
-
- 13 Jul, 2017 1 commit
-
-
Ross McIlroy authored
Removes the --ignition flag which is now on by default. Adds a --stress-fullcodegen flag which enables running all functions supported by fullcodegen to be compiled by fullcodegen. This will enable moving parser internalization later when we are not stressing fullcodegen or compiling asm.js functions. BUG=v8:5203, v8:6409, v8:6589 Change-Id: I7fa68016d4e734755434ec0b4e749ef65ffa7f4e Reviewed-on: https://chromium-review.googlesource.com/565569 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#46635}
-
- 30 Jun, 2017 1 commit
-
-
Mathias Bynens authored
The `FAST_` prefix doesn’t make much sense — they’re all just different cases with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS` vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either. This patch renames the FAST elements kinds as follows: - e.g. FAST_ELEMENTS => PACKED_ELEMENTS - e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS The following exceptions are left intact, for lack of a better name: - FAST_SLOPPY_ARGUMENTS_ELEMENTS - SLOW_SLOPPY_ARGUMENTS_ELEMENTS - FAST_STRING_WRAPPER_ELEMENTS - SLOW_STRING_WRAPPER_ELEMENTS This makes it easier to reason about elements kinds, and less confusing to explain how they’re used. R=jkummerow@chromium.org, cbruni@chromium.org BUG=v8:6548 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9 Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#46361}
-
- 02 May, 2017 2 commits
-
-
jkummerow authored
Give the IC one more chance to get itself into a state that's in line with Turbofan's capabilities and the following assertOptimized expectation. BUG=v8:6101,v8:6325 Review-Url: https://codereview.chromium.org/2848193003 Cr-Commit-Position: refs/heads/master@{#45020}
-
Wiktor Garbacz authored
BUG=v8:6325 Change-Id: I5a638c47b33d6e75d31f020c499ffd084348fea4 Reviewed-on: https://chromium-review.googlesource.com/489505 Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Cr-Commit-Position: refs/heads/master@{#45010}
-
- 28 Apr, 2017 1 commit
-
-
Mythri authored
1. Replaces --crankshaft with --opt in tests. 2. Also fixes presubmit to check for --opt flag when assertOptimized is used. 3. Updates testrunner/local/variants.py and v8_foozie.py to use --opt flag. This would mean, nooptimize variant means there are no optimizations. Not even with %OptimizeFunctionOnNextCall. Bug:v8:6325 Change-Id: I638e743d0773a6729c6b9749e2ca1e2537f12ce6 Reviewed-on: https://chromium-review.googlesource.com/490206 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#44985}
-
- 15 Mar, 2017 1 commit
-
-
leszeks authored
The function "foo" in "base_getter_test" was picking up a left-over optimised code object from foo's code map, the third time that base_getter_test was run, instead of optimising it itself. This broke the assumptions of the test, that each case was functionally independent from the others, and had started off with empty feedback and no optimised code. This breaks the test though, so we have to blacklist it pending a fix to the root cause (http://crbug.com/v8/6101). Review-Url: https://codereview.chromium.org/2750623004 Cr-Commit-Position: refs/heads/master@{#43828}
-
- 15 Feb, 2017 1 commit
-
-
ishell@chromium.org authored
BUG= Change-Id: I859fef6b18e51cca80343a89e2b6f38eee95d408 Reviewed-on: https://chromium-review.googlesource.com/442428 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#43206}
-
- 26 Jan, 2017 1 commit
-
-
ishell authored
This CL adds --crankshaft and --no-always-opt flags to the tests that use assertOptimized() and assertUnoptimized() respectively. This CL also adds presubmit checks that ensure that tests have the proper flags set. BUG=v8:5890 Review-Url: https://codereview.chromium.org/2653753007 Cr-Commit-Position: refs/heads/master@{#42709}
-
- 22 Oct, 2014 1 commit
-
-
adamk@chromium.org authored
setter-on-elements had the wrong length hardcoded in a for loop over the creation functions (getter-on-elements had the right length, but seemed worth future-proofing). R=mvstanton@chromium.org Review URL: https://codereview.chromium.org/643143005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24813 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Feb, 2014 1 commit
-
-
mvstanton@chromium.org authored
Map collection complicates a test that wants to assert on code opt/deopt because of prototype-chain changes. It can happen that a gc occurs in the stack guard at the start of optimized function foo that deopts function foo because of a map being collected and deoptimizing it's dependent code. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/159653002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19258 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Nov, 2013 1 commit
-
-
mvstanton@chromium.org authored
Our generic KeyedStoreIC doesn't handle the case when a callback is set on array elements in the prototype chain of the object, nor do we recognize that we need to avoid the monomorphic case if these callbacks exist. This CL addresses the issue by looking for dictionary elements in the prototype chain on IC misses and crankshaft element store instructions. When found, the generic IC is used. The generic IC is changed to go to the runtime in this case too. In general, keyed loads are immune from this problem because they won't return the hole: discovery of the hole goes to the runtime where the callback will be found in the prototype chain. Double array loads in crankshaft can return the hole but only if the prototype chain is unaltered (we will catch such alterations). Includes the following patch as well (already reviewed by bmeurer): Performance regression found in test regress-2185-2.js. The problem was that the bailout method for TransitionAndStoreStub was not performing the appropriate transition. (Review URL for the ElementsTransitionAndStoreIC_Miss change: https://codereview.chromium.org/26911007) R=danno@chromium.org Review URL: https://codereview.chromium.org/35413006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@17525 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-