1. 19 May, 2016 1 commit
  2. 06 May, 2016 1 commit
  3. 05 May, 2016 1 commit
  4. 15 Apr, 2016 1 commit
    • zhengxing.li's avatar
      X87: [ia32] Byte and word memory operands in ia32 cmp/test. · 39c39b54
      zhengxing.li authored
        port 3dd3beb0 (r35199)
      
        original commit message:
        Currently, if the size of two cmp or test operands is a byte or a word, we sign-extend or zero-extend each of them into a 32-bit register before doing the comparison, even when the conditions
        for the use of a memory operand are met.
      
        This CL makes it possible to load only one of them into a register and address the other as a memory operand.
      
        The tricky bit is that, unlike as in the x64 counterpart http://crrev.com/1780193003, not all registers can be accessed as bytes.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1883373002
      
      Cr-Commit-Position: refs/heads/master@{#35508}
      39c39b54
  5. 22 Mar, 2016 1 commit
  6. 10 Mar, 2016 1 commit
  7. 08 Mar, 2016 1 commit
    • zhengxing.li's avatar
      X87: [wasm] Int64Lowering of I64Shl on ia32. · 8f506ac6
      zhengxing.li authored
        port ddc626e1 (r34546)
      
        original commit message:
        I64Shl is lowered to a new turbofan operator, WasmWord64Shl. The new
        operator takes 3 inputs, the low-word input, the high-word input, and
        the shift, and produces 2 output, the low-word output and the high-word
        output.
      
        At the moment I implemented the lowering only for ia32, but I think the
        CL is already big enough. I will add the other platforms in separate
        CLs.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1773083002
      
      Cr-Commit-Position: refs/heads/master@{#34591}
      8f506ac6
  8. 23 Feb, 2016 1 commit
    • zhengxing.li's avatar
      X87: Emit memory operands for cmp and test on ia32 and x64 when it makes sense. · e1b9058f
      zhengxing.li authored
        port 0e43ff56 (r34187)
      
        original commit message:
        The InstructionSelector now associates an effect level to every node in a block.
      
        The effect level of a node is the number of non-eliminatable nodes encountered from the beginning of the block to the node itself.
      
        With this change, on ia32 and x64, a load from memory into a register can be replaced by a memory operand if all of the following conditions hold:
      
        1. The only use of the load is in a 32 or 64 bit word comparison.
        2. The user node and the load node belong to the same block.
        3. The values of the operands have the same size (i.e., no need to zero-extend or sign-extend the result of the load).
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1724473004
      
      Cr-Commit-Position: refs/heads/master@{#34204}
      e1b9058f
  9. 27 Nov, 2015 2 commits
  10. 25 Nov, 2015 1 commit
  11. 23 Oct, 2015 1 commit
  12. 10 Sep, 2015 1 commit
    • chunyang.dai's avatar
      X87: [builtins] Unify the various versions of [[Call]] with a Call builtin. · 20c9749b
      chunyang.dai authored
      port ccbb4ff0 (r30629)
      
      original commit message:
      
          The new Call and CallFunction builtins supersede the current
          CallFunctionStub (and CallIC magic) and will be the single bottleneck
          for all calling, including the currently special Function.prototype.call
          and Function.prototype.apply builtins, which had handwritten (and
          not fully compliant) versions of CallFunctionStub, and also the
          CallIC(s), which where also slightly different.
      
          This also reduces the overhead for API function calls, which is still
          unnecessary high, but let's do that step-by-step.
      
          This also fixes a bunch of cases where the implicit ToObject for
          sloppy receivers was done in the wrong context (in the caller
          context instead of the callee context), which basically meant
          that we allowed cross context access to %ObjectPrototype%.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/1332703002
      
      Cr-Commit-Position: refs/heads/master@{#30668}
      20c9749b
  13. 03 Sep, 2015 1 commit
  14. 17 Aug, 2015 1 commit
  15. 16 Jul, 2015 1 commit
  16. 13 Jul, 2015 1 commit
    • yangguo's avatar
      Debugger: refactor reloc info. · 198c75f6
      yangguo authored
      - split relocation info for debug break slots for
        - calls (with call arguments count as data)
        - construct calls
        - normal slots
      - renamed DEBUG_BREAK into DEBUGGER_STATEMENT
      - removed unused IC state for Debug stubs
      
      R=ulan@chromium.org
      BUG=v8:4269
      LOG=N
      
      Review URL: https://codereview.chromium.org/1232803002
      
      Cr-Commit-Position: refs/heads/master@{#29603}
      198c75f6
  17. 16 Jun, 2015 1 commit
  18. 04 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · eac7f046
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=bmeurer@chromium.org, rmcilroy@chromium.org, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1162993006
      
      Cr-Commit-Position: refs/heads/master@{#28801}
      eac7f046
  19. 03 Jun, 2015 1 commit
  20. 02 Jun, 2015 1 commit
    • mbrandy's avatar
      Add support for Embedded Constant Pools for PPC and Arm · a9404029
      mbrandy authored
      Embed constant pools within their corresponding Code
      objects.
      
      This removes support for out-of-line constant pools in favor
      of the new approach -- the main advantage being that it
      eliminates the need to allocate and manage separate constant
      pool array objects.
      
      Currently supported on PPC and ARM.  Enabled by default on
      PPC only.
      
      This yields a 6% improvment in Octane on PPC64.
      
      R=danno@chromium.org, svenpanne@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org, dstence@us.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:478811
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1131783003
      
      Cr-Commit-Position: refs/heads/master@{#28770}
      a9404029
  21. 01 Jun, 2015 1 commit
  22. 27 Mar, 2015 1 commit
  23. 05 Mar, 2015 1 commit
    • chunyang.dai's avatar
      X87: Refactor BreakLocationIterator · 7f78e7b3
      chunyang.dai authored
      port 1a608493 (r26983)
      
      original commit message:
      
         Refactor BreakLocationIterator.
      
         We now have BreakLocation::Iterator to iterate via RelocIterator, and
         create a BreakLocation when we are done iterating. The reloc info is
         stored in BreakLocation in a GC-safe way and instantiated on demand.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/978183002
      
      Cr-Commit-Position: refs/heads/master@{#27003}
      7f78e7b3
  24. 04 Mar, 2015 1 commit
    • yangguo's avatar
      Refactor BreakLocationIterator. · 1a608493
      yangguo authored
      We now have BreakLocation::Iterator to iterate via RelocIterator, and
      create a BreakLocation when we are done iterating. The reloc info is
      stored in BreakLocation in a GC-safe way and instantiated on demand.
      
      R=ulan@chromium.org
      BUG=v8:3924
      LOG=N
      
      Review URL: https://codereview.chromium.org/967323002
      
      Cr-Commit-Position: refs/heads/master@{#26983}
      1a608493
  25. 15 Feb, 2015 1 commit
  26. 13 Feb, 2015 1 commit
  27. 12 Feb, 2015 4 commits
    • loislo's avatar
      CPUProfiler: Push deopt reason further to ProfileNode. · d23ab23b
      loislo authored
      1) create beefy RelocInfo table when cpu profiler is active, so if a function
      was optimized when profiler was active RelocInfo would get separate DeoptInfo
      for the each deopt case.
      
      2) push DeoptInfo from CodeEntry to ProfileNode.
      When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
      On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
      
      Sample profile dump.
      [Top down]:
          0  (root) 0 #1
          1     29 #2
          1      test 29 #3
          2        opt_function 29 #4
          2          opt_function 29 #5
                         deopted at 118 with reason 'not a heap number'
                         deopted at 137 with reason 'division by zero'
      
      BUG=452067
      LOG=n
      
      Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54
      Cr-Commit-Position: refs/heads/master@{#26615}
      
      Review URL: https://codereview.chromium.org/919953002
      
      Cr-Commit-Position: refs/heads/master@{#26630}
      d23ab23b
    • loislo's avatar
      Revert of CPUProfiler: Push deopt reason further to ProfileNode. (patchset #1... · cb6ea146
      loislo authored
      Revert of CPUProfiler: Push deopt reason further to ProfileNode. (patchset #1 id:1 of https://codereview.chromium.org/919953002/)
      
      Reason for revert:
      static initializers broke the build
      
      Original issue's description:
      > CPUProfiler: Push deopt reason further to ProfileNode.
      >
      > 1) create beefy RelocInfo table when cpu profiler is active, so if a function
      > was optimized when profiler was active RelocInfo would get separate DeoptInfo
      > for the each deopt case.
      >
      > 2) push DeoptInfo from CodeEntry to ProfileNode.
      > When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
      > On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
      >
      > Sample profile dump.
      > [Top down]:
      >     0  (root) 0 #1
      >     1     29 #2
      >     5      test 29 #3
      >     3        opt_function 29 #4
      >                  deopted at 52 with reason 'not a heap number'
      >                  deopted at 71 with reason 'division by zero'
      >
      > BUG=452067
      > LOG=n
      >
      > Committed: https://crrev.com/ce8701b247d3c6604f24f17a90c02d17b4417f54
      > Cr-Commit-Position: refs/heads/master@{#26615}
      
      TBR=jarin@chromium.org,svenpanne@chromium.org,yurys@chromium.org,alph@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=452067
      
      Review URL: https://codereview.chromium.org/915173005
      
      Cr-Commit-Position: refs/heads/master@{#26616}
      cb6ea146
    • loislo's avatar
      CPUProfiler: Push deopt reason further to ProfileNode. · ce8701b2
      loislo authored
      1) create beefy RelocInfo table when cpu profiler is active, so if a function
      was optimized when profiler was active RelocInfo would get separate DeoptInfo
      for the each deopt case.
      
      2) push DeoptInfo from CodeEntry to ProfileNode.
      When deopt happens we put the info collected on #1 into CodeEntry and record stack sample.
      On the sampling thread we grab the deopt data and append it to the corresponding ProfileNode deopts list.
      
      Sample profile dump.
      [Top down]:
          0  (root) 0 #1
          1     29 #2
          5      test 29 #3
          3        opt_function 29 #4
                       deopted at 52 with reason 'not a heap number'
                       deopted at 71 with reason 'division by zero'
      
      BUG=452067
      LOG=n
      
      Review URL: https://codereview.chromium.org/919953002
      
      Cr-Commit-Position: refs/heads/master@{#26615}
      ce8701b2
    • danno's avatar
      Remove redundant source position information in RelocInfo · e87c0bac
      danno authored
      Previously, emitting two more more unique source positions at the same pc would
      generate two or more RelocInfo entries. Now, only the last emitted source
      position for any pc is added to the RelocInfo.
      
      Review URL: https://codereview.chromium.org/908443002
      
      Cr-Commit-Position: refs/heads/master@{#26608}
      e87c0bac
  28. 09 Feb, 2015 1 commit
    • chunyang.dai's avatar
      X87: Externalize deoptimization reasons. · ebb77c37
      chunyang.dai authored
      port 2491a639 (r26463)
      
      original commit message:
      
         Externalize deoptimization reasons.
         1) The hardcoded strings were converted into DeoptReason enum.
      
         2) Deopt comment were converted into a pair location and deopt reason entries so
            the deopt reason tracking mode would less affect the size of the RelocInfo table and heap.
      
         3) DeoptReason entry in RelocInfo reuses kCommentTag value and generates short entry in RelocInfo table.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/867243005
      
      Cr-Commit-Position: refs/heads/master@{#26526}
      ebb77c37
  29. 08 Oct, 2014 1 commit
  30. 26 Sep, 2014 1 commit
  31. 20 Sep, 2014 1 commit
  32. 03 Sep, 2014 1 commit
  33. 07 Aug, 2014 1 commit
  34. 06 Aug, 2014 1 commit
  35. 04 Aug, 2014 1 commit
  36. 01 Aug, 2014 1 commit