1. 17 Sep, 2018 1 commit
  2. 30 Apr, 2018 1 commit
  3. 28 Apr, 2018 1 commit
  4. 25 Sep, 2017 1 commit
  5. 31 Jul, 2017 1 commit
  6. 28 Jul, 2017 4 commits
  7. 03 Jan, 2017 1 commit
  8. 04 Nov, 2016 1 commit
    • leszeks's avatar
      [turbofan] Do not replace actual duplicates when value numbering · b7761100
      leszeks authored
      The value numbering reducer has collision checks for nodes that mutated,
      but kept the same hash, and are now equivalent to another node. However,
      it can also accidentally hit itself, if it mutated, changed hash, but
      ran over the location it was previously in.
      
      After this patch, it checks to see if it is comparing against itself,
      and skips over itself. Additionally, if this check is at the end of the
      collisions, it opportunistically removes the duplicate entry and reduces
      the size pressure on the list. We can do the same opportunistic clean up
      if we happen to find a colliding equivalent entry, since we move it from
      its original position to a new one.
      
      Drive-by change: Ensure that the collision replacement checks types in
      the same way that normal replacement does.
      
      Review-Url: https://codereview.chromium.org/2475653002
      Cr-Commit-Position: refs/heads/master@{#40757}
      b7761100
  9. 03 Nov, 2016 1 commit
  10. 17 Aug, 2016 1 commit
    • jarin's avatar
      [turbofan] Only do value numbering when types are compatible. · b190d133
      jarin authored
      At the moment, two NumberConstant nodes get different type even if their
      value is the same because we always allocate a new heap number for
      each number constant. This can lead to replacing a node with a node of
      disjoint type in value numbering, which can result in incorrect code
      down the line because of inconsistent types.
      
      This fix makes sure that we only replace a node with a sub-type
      node. Once we introduce a proper type for number constants, we can
      move back to the intersection typing in value numbering.
      
      Unfortunately, it is quite hard to write a repro for this because we cache NumberConstant nodes. We only throw away cached values that have too many conflicts (>5), so the test has to contain values that fall into the same bucket. That's where the magic floating point numbers in the test come from (they have the same low 8-bits of their hashes).
      
      BUG=chromium:633497
      
      Review-Url: https://codereview.chromium.org/2251833002
      Cr-Commit-Position: refs/heads/master@{#38675}
      b190d133
  11. 14 Jul, 2016 1 commit
  12. 12 Feb, 2015 1 commit
  13. 11 Feb, 2015 1 commit
  14. 17 Dec, 2014 1 commit
  15. 27 Oct, 2014 2 commits
  16. 08 Oct, 2014 1 commit
  17. 05 Sep, 2014 2 commits
  18. 04 Sep, 2014 1 commit