1. 07 Sep, 2016 1 commit
  2. 25 Aug, 2016 4 commits
    • baptiste.afsa's avatar
      [turbofan] Instruction scheduler: keep ready nodes list sorted by latency. · f93ca29c
      baptiste.afsa authored
      This significantly speed-up the instruction scheduler when the ready list
      contains a large number of instruction.
      
      R=jarin@chromium.org, bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2281523002
      Cr-Commit-Position: refs/heads/master@{#38919}
      f93ca29c
    • jarin's avatar
      Reland of [turbofan] Insert dummy values when changing from None type. · 2a97b1bc
      jarin authored
      This reverts commit a55fdb1e, relands
      https://codereview.chromium.org/2266823002/.
      
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2277283002
      Cr-Commit-Position: refs/heads/master@{#38917}
      2a97b1bc
    • bmeurer's avatar
      Revert of [turbofan] Insert dummy values when changing from None type.... · a55fdb1e
      bmeurer authored
      Revert of [turbofan] Insert dummy values when changing from None type. (patchset #5 id:80001 of https://codereview.chromium.org/2266823002/ )
      
      Reason for revert:
      Octane/Mandreel aborts with an exception now:
      
      TypeError: __FUNCTION_TABLE__[(r2 >> 2)] is not a function
      
      Original issue's description:
      > [turbofan] Insert dummy values when changing from None type.
      >
      > Currently we choose the MachineRepresentation::kNone representation for
      > values of Type::None, and when converting values from the kNone representation
      > we use "impossible" conversions that will crash at runtime. This
      > assumes that the impossible conversions should never be hit (the only
      > way to produce the impossible values is to perform an always-failing
      > runtime check on a value, such as Smi-checking a string). Note that
      > this assumes that the runtime check is executed before the impossible
      > convesrion.
      >
      > Introducing BitwiseOr type feedback broke this in two ways:
      >
      > - we always pick Word32 representation for bitwise-or, so the
      >   impossible conversion does not trigger (it only triggers with
      >   None representation), and we could end up with unsupported
      >   conversions from Word32.
      >
      > - even if we inserted impossible conversions, they are pure conversions.
      >   Since untagging, bitwise-or operations are also pure, we could hoist
      >   all these before the smi check of the inputs and we could hit the
      >   impossible conversions before we get to the smi check.
      >
      > This CL addresses this by just providing dummy values for conversions
      > from the Type::None type. It also removes the impossible-to-* conversions.
      >
      > BUG=chromium:638132
      >
      > Committed: https://crrev.com/c83b21ab755f1420b6da85b3ff43d7e96ead9bbe
      > Cr-Commit-Position: refs/heads/master@{#38883}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2280613002
      Cr-Commit-Position: refs/heads/master@{#38893}
      a55fdb1e
    • jarin's avatar
      [turbofan] Insert dummy values when changing from None type. · c83b21ab
      jarin authored
      Currently we choose the MachineRepresentation::kNone representation for
      values of Type::None, and when converting values from the kNone representation
      we use "impossible" conversions that will crash at runtime. This
      assumes that the impossible conversions should never be hit (the only
      way to produce the impossible values is to perform an always-failing
      runtime check on a value, such as Smi-checking a string). Note that
      this assumes that the runtime check is executed before the impossible
      convesrion.
      
      Introducing BitwiseOr type feedback broke this in two ways:
      
      - we always pick Word32 representation for bitwise-or, so the
        impossible conversion does not trigger (it only triggers with
        None representation), and we could end up with unsupported
        conversions from Word32.
      
      - even if we inserted impossible conversions, they are pure conversions.
        Since untagging, bitwise-or operations are also pure, we could hoist
        all these before the smi check of the inputs and we could hit the
        impossible conversions before we get to the smi check.
      
      This CL addresses this by just providing dummy values for conversions
      from the Type::None type. It also removes the impossible-to-* conversions.
      
      BUG=chromium:638132
      
      Review-Url: https://codereview.chromium.org/2266823002
      Cr-Commit-Position: refs/heads/master@{#38883}
      c83b21ab
  3. 15 Aug, 2016 1 commit
  4. 25 Jul, 2016 1 commit
  5. 01 Jul, 2016 1 commit
    • bmeurer's avatar
      [builtins] Unify most of the remaining Math builtins. · 0a0fe8fb
      bmeurer authored
      Import fdlibm versions of acos, acosh, asin and asinh, which are more
      precise and produce the same result across platforms (we were using
      libm versions for asin and acos so far, where both speed and precision
      depended on the operating system so far). Introduce appropriate TurboFan
      operators for these functions and use them both for inlining and for the
      generic builtin.
      
      Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
      to ensure that their behavior is always exactly the same as the inlined
      TurboFan version (i.e. C++ truncation semantics for double to float
      don't necessarily meet the JavaScript semantics).
      
      For completeness, also migrate Math.sign, which can even get some nice
      love in TurboFan.
      
      Drive-by-fix: Some alpha-sorting on the Math related functions, and
      cleanup the list of Math intrinsics that we have to export via the
      native context currently.
      
      BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
      TBR=rossberg@chromium.org
      R=franzih@chromium.org
      
      Review-Url: https://codereview.chromium.org/2116753002
      Cr-Commit-Position: refs/heads/master@{#37476}
      0a0fe8fb
  6. 30 Jun, 2016 1 commit
  7. 28 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      bmeurer authored
      Introduce a new machine operator Float64Pow that for now is backed by
      the existing MathPowStub to start the unification of Math.pow, and at
      the same time address the main performance issue that TurboFan still has
      with the imaging-darkroom benchmark in Kraken.
      
      Also migrate the Math.pow builtin itself to a TurboFan builtin and
      remove a few hundred lines of hand-written platform code for special
      handling of the fullcodegen Math.pow version.
      
      BUG=v8:3599,v8:5086,v8:5157
      
      Review-Url: https://codereview.chromium.org/2103733003
      Cr-Commit-Position: refs/heads/master@{#37323}
      e607e12e
  8. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
      operator based on that, similar to what we do for Float64Cos and Float64Sin.
      Rewrite Math.tan() as TurboFan builtin and use those operators to also
      inline Math.tan() into optimized TurboFan functions.
      
      Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
      the %ConstructDouble runtime entry for writing tests.
      
      BUG=v8:5086,v8:5126
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2083453002
      Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc
  9. 17 Jun, 2016 3 commits
  10. 16 Jun, 2016 3 commits
  11. 13 Jun, 2016 2 commits
    • bmeurer's avatar
      [builtins] Introduce proper Float64Atan and Float64Atan2 operators. · 89d8c57b
      bmeurer authored
      Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
      introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
      similar to what we already did for Float64Log and Float64Log1p. Rewrite
      Math.atan() and Math.atan2() as TurboFan builtin and use the operators
      to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5095
      
      Review-Url: https://codereview.chromium.org/2065503002
      Cr-Commit-Position: refs/heads/master@{#36916}
      89d8c57b
    • bmeurer's avatar
      [builtins] Introduce proper Float64Log1p operator. · 7ceed92a
      bmeurer authored
      Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.log1p() as TurboFan builtin and use that operator to also
      inline Math.log1p() into optimized TurboFan functions.
      
      Also unify the handling of the special IEEE 754 functions somewhat in
      the TurboFan backends. At some point we can hopefully express this
      completely in the InstructionSelector (once we have an idea what to do
      with the ST(0) return issue on IA-32/X87).
      
      Drive-by-fix: Add some more test coverage for the log function.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5092
      
      Review-Url: https://codereview.chromium.org/2060743002
      Cr-Commit-Position: refs/heads/master@{#36914}
      7ceed92a
  12. 10 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper base::ieee754::log. · d0c7775d
      bmeurer authored
      This switches Math.log to use an fdlibm based version of log, imported
      as base::ieee754::log, and use that consistently everywhere, i.e. change
      the Float64Log TurboFan operators on Intel to use the C++ implementation
      as well (same for Crankshaft).
      
      R=yangguo@chromium.org
      BUG=v8:5065,v8:5086
      
      Review-Url: https://codereview.chromium.org/2053893003
      Cr-Commit-Position: refs/heads/master@{#36880}
      d0c7775d
  13. 09 Jun, 2016 1 commit
  14. 19 May, 2016 1 commit
  15. 03 May, 2016 1 commit
  16. 21 Apr, 2016 1 commit
  17. 18 Apr, 2016 1 commit
  18. 16 Apr, 2016 2 commits
  19. 14 Apr, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Make dispatch table point to code entry instead of code objects. · 0c05e02f
      rmcilroy authored
      Modifies Ignition to store code entry addresses in the dispatch table
      rather than code objects. This allows the interpreter to avoid
      calculating the code entry address from the code object on every
      dispatch and provides a ~5-7% performance improvement on Octane with
      Ignition.
      
      This change adds ArchOpcode::kArchTailCallAddress to TurboFan to enable
      tail call dispatch using these code addresses. It also adds a Dispatch
      linkage creator (distinct from the stub linkage type used previously) to
      allow targetting a code address target (which will diverge further from
      the stub linkage type when we remove the context machine register in
      Ignition).
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1882073002
      
      Cr-Commit-Position: refs/heads/master@{#35480}
      0c05e02f
  20. 08 Mar, 2016 1 commit
    • ishell's avatar
      [turbofan] Further fixing ES6 tail call elimination in Turbofan. · 2aae579c
      ishell authored
      In case when F tail calls G we should also remove the potential arguments adaptor frame for F.
      
      This CL introduces two new machine instructions ArchTailCallCodeObjectFromJSFunction and ArchTailCallJSFunctionFromJSFunction which (unlike existing ArchTailCallCodeObject and ArchTailCallJSFunction) also drop arguments adaptor frame if it exists right before jumping to the target function.
      
      BUG=v8:4698
      LOG=N
      
      Review URL: https://codereview.chromium.org/1702423002
      
      Cr-Commit-Position: refs/heads/master@{#34566}
      2aae579c
  21. 29 Feb, 2016 1 commit
  22. 19 Feb, 2016 2 commits
  23. 16 Feb, 2016 2 commits
    • mstarzinger's avatar
      [turbofan] Remove support for LazyBailout operators. · aa31ff31
      mstarzinger authored
      The LazyBailout operator (modelled as a nop-call) was introduced for
      placing a deoptimization point into exception handlers. Now that we are
      no longer re-entering lazy deoptimized code, the support can be removed.
      
      R=jarin@chromium.org
      BUG=v8:4195
      LOG=n
      
      Review URL: https://codereview.chromium.org/1697503002
      
      Cr-Commit-Position: refs/heads/master@{#34020}
      aa31ff31
    • danno's avatar
      [turbofan] Add an operator to access the parent frame pointer · fd8fd05c
      danno authored
      This functionality is useful for stubs that need to walk the stack. The new
      machine operator, LoadParentFramePointer dosn't force the currently compiling
      method to have a frame in contrast to LoadFramePointer. Instead, it adapts
      accordingly when frame elision is possible, making efficient stack walks
      possible without incurring a performance penalty for small stubs that can
      benefit from frame elision.
      
      R=bmeurer@chromium.org
      LOG=N
      
      Review URL: https://codereview.chromium.org/1695313002
      
      Cr-Commit-Position: refs/heads/master@{#34014}
      fd8fd05c
  24. 29 Jan, 2016 3 commits
    • ahaas's avatar
      [turbofan] Add the StackSlot operator to turbofan. · 64588037
      ahaas authored
      The StackSlot operator allows to allocate a spill slot on the stack. We
      are going to use this operator to pass floats through pointers to c
      functions, which we need for floating point rounding in the case where
      the architecture does not provide rounding instructions.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
      
      Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
      Cr-Commit-Position: refs/heads/master@{#33600}
      
      Review URL: https://codereview.chromium.org/1645653002
      
      Cr-Commit-Position: refs/heads/master@{#33606}
      64588037
    • ahaas's avatar
      Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4... · 11f7c2e6
      ahaas authored
      Revert of [turbofan] Add the StackSlot operator to turbofan. (patchset #4 id:60001 of https://codereview.chromium.org/1645653002/ )
      
      Reason for revert:
      problems on Mac64
      
      Original issue's description:
      > [turbofan] Add the StackSlot operator to turbofan.
      >
      > The StackSlot operator allows to allocate a spill slot on the stack. We
      > are going to use this operator to pass floats through pointers to c
      > functions, which we need for floating point rounding in the case where
      > the architecture does not provide rounding instructions.
      >
      > R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
      >
      > Committed: https://crrev.com/7a693437787090d62d937b862e29521debcc5223
      > Cr-Commit-Position: refs/heads/master@{#33600}
      
      TBR=titzer@chromium.org,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,v8-ppc-ports@googlegroups.com
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1644283002
      
      Cr-Commit-Position: refs/heads/master@{#33601}
      11f7c2e6
    • ahaas's avatar
      [turbofan] Add the StackSlot operator to turbofan. · 7a693437
      ahaas authored
      The StackSlot operator allows to allocate a spill slot on the stack. We
      are going to use this operator to pass floats through pointers to c
      functions, which we need for floating point rounding in the case where
      the architecture does not provide rounding instructions.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-ppc-ports@googlegroups.com, v8-mips-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1645653002
      
      Cr-Commit-Position: refs/heads/master@{#33600}
      7a693437
  25. 15 Dec, 2015 3 commits