1. 01 Apr, 2016 2 commits
  2. 29 Mar, 2016 1 commit
  3. 22 Mar, 2016 1 commit
  4. 21 Mar, 2016 1 commit
    • jyan's avatar
      S390: Disable gcc generation of mul-add in cctests · faaf8512
      jyan authored
      Generated code performs distinct floating multiply and add/subtract
      operations. Tests fail when GCC uses mul-add to calculate the
      expected result since these instructions provide higher accuracy due
      to the lack of an intermediate round.
      
      R=machenbach@chromium.org, mbrandy@us.ibm.com, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      
      Review URL: https://codereview.chromium.org/1812823008
      
      Cr-Commit-Position: refs/heads/master@{#34953}
      faaf8512
  5. 17 Mar, 2016 1 commit
  6. 16 Mar, 2016 3 commits
  7. 15 Mar, 2016 1 commit
  8. 04 Mar, 2016 1 commit
  9. 29 Feb, 2016 1 commit
  10. 26 Feb, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Bailout if LoadBuffer typing assumption doesn't hold. · 58ab990a
      bmeurer authored
      The LoadBuffer operator that is used for asm.js heap access claims to
      return only the appropriate typed array type, but out of bounds access
      could make it return undefined. So far we tried to "repair" the graph
      later if we see that our assumption was wrong, and for various reasons
      that worked for some time. But now that wrong type information that is
      propagated earlier is picked up appropriately and thus we generate wrong
      code, i.e. we in the repro case we feed NaN into ChangeFloat64Uint32 and
      thus get 2147483648 instead of 0 (with proper JS truncation).
      
      This was always considered a temporary hack until we have a proper
      asm.js pipeline, but since we still run asm.js through the generic
      JavaScript pipeline, we have to address this now. Quickfix is to just
      bailout from the pipeline when we see that the LoadBuffer type was
      wrong, i.e. the result of LoadBuffer is not properly truncated and thus
      undefined or NaN would be observable.
      
      R=mstarzinger@chromium.org, jarin@chromium.org
      BUG=chromium:589792
      LOG=y
      
      Review URL: https://codereview.chromium.org/1740123002
      
      Cr-Commit-Position: refs/heads/master@{#34322}
      58ab990a
  11. 25 Feb, 2016 1 commit
  12. 24 Feb, 2016 1 commit
    • ulan's avatar
      Revert of Replace slots buffer with remembered set. (patchset #14 id:250001 of... · 9146bc5e
      ulan authored
      Revert of Replace slots buffer with remembered set. (patchset #14 id:250001 of https://codereview.chromium.org/1703823002/ )
      
      Reason for revert:
      Revert because of canary crashes: crbug.com/589413
      
      Original issue's description:
      > Replace slots buffer with remembered set.
      >
      > Slots pointing to evacuation candidates are now recorded in the new RememberedSet<OLD_TO_OLD>.
      >
      > The remembered set is extended to support typed slots.
      >
      > During parallel evacuation all migration slots are recorded in local slots buffers.
      > After evacuation all local slots are added to the remembered set.
      >
      > BUG=chromium:578883
      > LOG=NO
      >
      > Committed: https://crrev.com/2285a99ef6f7d52f4f0c4d88a7db4224443ee152
      > Cr-Commit-Position: refs/heads/master@{#34212}
      
      TBR=jochen@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:578883
      
      Review URL: https://codereview.chromium.org/1725073003
      
      Cr-Commit-Position: refs/heads/master@{#34238}
      9146bc5e
  13. 23 Feb, 2016 2 commits
  14. 15 Feb, 2016 2 commits
    • ssanfilippo's avatar
      [Interpreter] Change the output format of generate-bytecode-expectations. · e082ebdb
      ssanfilippo authored
      Now the tool produces a far more readable output format, which bears a
      lot of resemblance to YAML. In fact, the output should be machine
      parseable as such, one document per testcase. However, the output format
      may be subject to changes in future, so don't rely on this property.
      
      In general, the output format has been optimized for producing a meaningful
      textual diff, while keeping a decent readability as well. Therefore, not
      everything is as compact as it could be, e.g. for an empty const pool we get:
      
          constant pool: [
          ]
      
      instead of:
      
          constant pool: []
      
      Also, trailing commas are always inserted in lists.
      
      Additionally, now the tool accepts its output format as input. When
      operating in this mode, all the snippets are extracted, processed and
      the output is then emitted as usual. If nothing has changed, the output
      should match the input. This is very useful for catching bugs in the
      bytecode generation by running a textual diff against a known-good file.
      
      The core (namely bytecode-expectations.cc) has been extracted from the
      original cc file, which provides the utility as usual. The definitions
      in the matching header of the library have been moved into the
      v8::internal::interpreter namespace.
      
      The library exposes a class ExpectationPrinter, with a method
      PrintExpectation, which takes a test snippet as input, and writes the
      formatted expectation to the supplied stream. One might then use a
      std::stringstream to retrieve the results as a string and run it through
      a diff utility.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1688383003
      
      Cr-Commit-Position: refs/heads/master@{#33997}
      e082ebdb
    • machenbach's avatar
      [Swarming] Isolate perf tests. · 05218010
      machenbach authored
      This is to enable deduplicating performance tests. We'll
      create a hash of all relevant files and send it to perf bots
      alongside the other swarming hashes (follow up on infra
      side).
      
      This will not actually run on swarming yet, but could at
      some later point.
      
      This splits off the cctest executable from other verification
      test files, as those are not needed in performance tests.
      
      BUG=chromium:535160
      LOG=n
      
      Review URL: https://codereview.chromium.org/1695243002
      
      Cr-Commit-Position: refs/heads/master@{#33989}
      05218010
  15. 10 Feb, 2016 1 commit
    • ssanfilippo's avatar
      [Interpreter] Initial generate-bytecode-expectations implementation. · d3604cdb
      ssanfilippo authored
      generate-bytecode-expectations is a tool intended to work together
      with test/cctest/test-bytecode-generator.cc in order to produce a
      meaningful diff between testcases and the actual bytecode being emitted.
      
      It does so by parsing and compiling Javascript to bytecode,
      constructing the same data structure in the testcase and then running a
      textual diff between the expected (i.e. the one encoded in the unit test)
      and actual (i.e. the one built from the compiler output) representation.
      
      This commit is a first step in this direction, achieving just the first
      half of what we desire. At the moment, bytecodechecker can:
      
      * take a code snippet from the command line and emit the expected structure.
      * adhere to the same formatting rules of the test cases
        (this one is important for text diff and for copy and pasting too)
      
      Still to do:
      
      * parse unit tests:
          + extract code snippets
          + indent the code to match the input test case
          + allow flexibility in the input format
          + try to recognize and work around some macro magic (i.e. REPEAT_127)
      * emit the representation of the constant pool and handlers vector
      * run a textual diff
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1671863002
      
      Cr-Commit-Position: refs/heads/master@{#33863}
      d3604cdb
  16. 14 Jan, 2016 2 commits
  17. 13 Jan, 2016 2 commits
  18. 05 Jan, 2016 1 commit
  19. 18 Dec, 2015 1 commit
    • mlippautz's avatar
      [heap] Move to LAB-based allocation for newspace evacuation. · a4e3a3b6
      mlippautz authored
      This CL prepare newspace evacuation for parallel execution wrt. to actual
      allocations. The priority for allocations is:
      * Try to allocate from LAB if objects are below kMaxLabObjectSize
      * Allocate directly (synchronized) from newspace for larger objects.
      * Fall back to old space allocation (which will be backed by a local compaction
        space in future).
      
      Semantical change: Previously we did fall back to regular new space promotion if
      we are OOM in old space. With this CL we fall back to new space promotion, which
      could fail because of fragmentation, again leading to an old space allocation
      that finally bails into OOM.
      
      Newspace evacuation is still single threaded and requires further changes to
      allocation site tracking.
      
      BUG=chromium:524425
      LOG=N
      
      Review URL: https://codereview.chromium.org/1487853002
      
      Cr-Commit-Position: refs/heads/master@{#32970}
      a4e3a3b6
  20. 17 Dec, 2015 3 commits
  21. 16 Dec, 2015 1 commit
    • mlippautz's avatar
      Reland of "[cctest] Add tests for aborting compaction of pages" · 2bb51df9
      mlippautz authored
      Tests for
      * aborting a full page.
      * partially aborting a page.
      * partially aborting a page with pointers between aborted pages.
      * partially aborting a page with store buffer entries.
      
      Also introduces force_oom() which prohibits a old space to
      expand
      
      BUG=chromium:524425
      LOG=N
      
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel,v8_linux_nosnap_dbg,v8_win_nosnap_shared_rel,v8_win_nosnap_shared_compile_rel
      
      Review URL: https://codereview.chromium.org/1518803005
      
      Cr-Commit-Position: refs/heads/master@{#32899}
      2bb51df9
  22. 11 Dec, 2015 4 commits
  23. 10 Dec, 2015 4 commits
  24. 09 Dec, 2015 1 commit
  25. 03 Dec, 2015 1 commit