1. 26 Jul, 2016 1 commit
  2. 13 Jul, 2016 1 commit
  3. 29 Jun, 2016 1 commit
  4. 28 Jun, 2016 3 commits
  5. 27 Jun, 2016 1 commit
    • ssanfilippo's avatar
      This commit is the first step towards emitting unwinding information in · 7d073b03
      ssanfilippo authored
      the .eh_frame format as part of the jitdump generated when
      FLAG_perf_prof is enabled. The final goal is allowing precise unwinding
      of callchains that include JITted code when profiling V8 using perf.
      
      Unwinding information is stored in the body of code objects after the
      code itself, prefixed with its length and aligned to a 8-byte boundary.
      A boolean flag in the header signals its presence, resulting in zero
      memory overhead when the generation of unwinding info is disabled or
      no such information was attached to the code object.
      
      A new jitdump record type (with id 4) is introduced for specifying
      optional unwinding information for code load records. The EhFrameHdr
      struct is also introduced, together with a constructor to initialise it
      from the associated code object.
      
      At this stage no unwinding information is written to the jitdump, but
      the infrastructure for doing so is ready in place.
      
      BUG=v8:4899
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1993653003
      Cr-Commit-Position: refs/heads/master@{#37296}
      7d073b03
  6. 20 Jun, 2016 2 commits
    • yangguo's avatar
      Simplify AssemblerPositionsRecorder. · 9c3d730d
      yangguo authored
      R=bmeurer@chromium.org, jgruber@chromium.org
      
      Review-Url: https://codereview.chromium.org/2072963003
      Cr-Commit-Position: refs/heads/master@{#37089}
      9c3d730d
    • mtrofin's avatar
      [wasm] Separate compilation from instantiation · c1d01aea
      mtrofin authored
      Compilation of wasm functions happens before instantiation. Imports are linked afterwards, at instantiation time. Globals and memory are also
      allocated and then tied in via relocation at instantiation time.
      
      This paves the way for implementing Wasm.compile, a prerequisite to
      offering the compiled code serialization feature.
      
      Currently, the WasmModule::Compile method just returns a fixed array
      containing the code objects. More appropriate modeling of the compiled module to come.
      
      Opportunistically centralized the logic on how to update memory
      references, size, and globals, since that logic is the exact same on each
      architecture, except for the actual storing of values back in the
      instruction stream.
      
      BUG=v8:5072
      
      Review-Url: https://codereview.chromium.org/2056633002
      Cr-Commit-Position: refs/heads/master@{#37086}
      c1d01aea
  7. 14 Jun, 2016 1 commit
  8. 19 May, 2016 3 commits
  9. 04 May, 2016 1 commit
    • gdeepti's avatar
      Add new relocation type WASM_MEMORY_SIZE_REFERENCE, use relocatable pointers... · 117a56b7
      gdeepti authored
      Add new relocation type WASM_MEMORY_SIZE_REFERENCE, use relocatable pointers to update wasm memory size references in generated code.
       - Add new RelocInfo mode WASM_MEMORY_SIZE_REFERENCE in the assembler and add relocation information to immediates in compare instructions.
       - Use relocatable constants for MemSize/BoundsCheck in the wasm compiler
      
      R=titzer@chromium.org, yangguo@chromium.org, bradnelson@chromium.org
      
      Review-Url: https://codereview.chromium.org/1921203002
      Cr-Commit-Position: refs/heads/master@{#36044}
      117a56b7
  10. 03 May, 2016 1 commit
  11. 01 Apr, 2016 1 commit
    • epertoso's avatar
      [ia32] Byte and word memory operands in ia32 cmp/test. · 3dd3beb0
      epertoso authored
      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/1845603002
      
      Cr-Commit-Position: refs/heads/master@{#35199}
      3dd3beb0
  12. 21 Mar, 2016 1 commit
  13. 09 Mar, 2016 1 commit
  14. 07 Mar, 2016 1 commit
    • ahaas's avatar
      [wasm] Int64Lowering of I64Shl on ia32. · ddc626e1
      ahaas authored
      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.
      
      R=titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1756863002
      
      Cr-Commit-Position: refs/heads/master@{#34546}
      ddc626e1
  15. 22 Feb, 2016 1 commit
    • epertoso's avatar
      Emit memory operands for cmp and test on ia32 and x64 when it makes sense. · 0e43ff56
      epertoso authored
      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/1706763002
      
      Cr-Commit-Position: refs/heads/master@{#34187}
      0e43ff56
  16. 18 Jan, 2016 2 commits
    • ahaas's avatar
      Revert of [turbofan] Implement rounding of floats on x64 and ia32 without... · 900b2933
      ahaas authored
      Revert of [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1. (patchset #2 id:20001 of https://codereview.chromium.org/1584663007/ )
      
      Reason for revert:
      Code is incorrect for -0.
      
      Original issue's description:
      > [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1.
      >
      > The implementation sets the rounding mode flag and then uses the
      > cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
      > the rounding. Input values outside int range either don't have to be
      > rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
      > positive inputs, or input -2^52 + 2^52 for negative inputs. The original
      > rounding mode is restored afterwards.
      >
      > R=titzer@chromium.org
      >
      > B=575379
      >
      > Committed: https://crrev.com/fa5d09e547abe79a8c82f780deb980c53ad78beb
      > Cr-Commit-Position: refs/heads/master@{#33367}
      
      TBR=titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1593313010
      
      Cr-Commit-Position: refs/heads/master@{#33369}
      900b2933
    • ahaas's avatar
      [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1. · fa5d09e5
      ahaas authored
      The implementation sets the rounding mode flag and then uses the
      cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
      the rounding. Input values outside int range either don't have to be
      rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
      positive inputs, or input -2^52 + 2^52 for negative inputs. The original
      rounding mode is restored afterwards.
      
      R=titzer@chromium.org
      
      B=575379
      
      Review URL: https://codereview.chromium.org/1584663007
      
      Cr-Commit-Position: refs/heads/master@{#33367}
      fa5d09e5
  17. 16 Jan, 2016 1 commit
    • ahaas's avatar
      [turbofan] Add the RoundInt32ToFloat32 operator to turbofan. · e06f7d78
      ahaas authored
      The new operator converts an int32 input to float32. If the input cannot
      be represented exactly in float32, the value is rounded using the
      round-ties-even rounding mode (the default rounding mode).
      
      I provide implementations of the new operator for x64, ia32, arm, arm64,
      mips, mips64, ppc, and ppc64.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com, v8-ppc-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1589363002
      
      Cr-Commit-Position: refs/heads/master@{#33347}
      e06f7d78
  18. 27 Nov, 2015 2 commits
  19. 25 Nov, 2015 2 commits
  20. 15 Oct, 2015 1 commit
  21. 08 Sep, 2015 3 commits
    • bmeurer's avatar
      [builtins] Unify the various versions of [[Call]] with a Call builtin. · ccbb4ff0
      bmeurer authored
      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%.
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      BUG=v8:4413
      LOG=n
      
      Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
      Cr-Commit-Position: refs/heads/master@{#30627}
      
      Review URL: https://codereview.chromium.org/1311013008
      
      Cr-Commit-Position: refs/heads/master@{#30629}
      ccbb4ff0
    • bmeurer's avatar
      Revert of [builtins] Unify the various versions of [[Call]] with a Call... · 298d4a6b
      bmeurer authored
      Revert of [builtins] Unify the various versions of [[Call]] with a Call builtin. (patchset #10 id:260001 of https://codereview.chromium.org/1311013008/ )
      
      Reason for revert:
      Breaks nosnap, needs investigation
      
      Original issue's description:
      > [builtins] Unify the various versions of [[Call]] with a Call builtin.
      >
      > 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%.
      >
      > MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      >
      > R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
      > BUG=v8:4413
      > LOG=n
      >
      > Committed: https://crrev.com/ef268a83be4dead004047c25b702319ea4be7277
      > Cr-Commit-Position: refs/heads/master@{#30627}
      
      TBR=rmcilroy@chromium.org,jarin@chromium.org,mstarzinger@chromium.org,mvstanton@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4413
      
      Review URL: https://codereview.chromium.org/1328963004
      
      Cr-Commit-Position: refs/heads/master@{#30628}
      298d4a6b
    • bmeurer's avatar
      [builtins] Unify the various versions of [[Call]] with a Call builtin. · ef268a83
      bmeurer authored
      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%.
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=mstarzinger@chromium.org, jarin@chromium.org, mvstanton@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg
      BUG=v8:4413
      LOG=n
      
      Review URL: https://codereview.chromium.org/1311013008
      
      Cr-Commit-Position: refs/heads/master@{#30627}
      ef268a83
  22. 12 Aug, 2015 1 commit
    • jfb's avatar
      Security: disable nontemporals. · a904b569
      jfb authored
      The operations were available on ARM64 and x86-32 but were unused.
      
      It has been conjectured that nontemporals can be used for rowhammer-like bitflips more easily than regular load/store operations. It is therefore desirable to avoid generating these instructions in the future.
      
      R= titzer, jochen, jln, Mark Seaborn, ruiq
      
      Review URL: https://codereview.chromium.org/1276113002
      
      Cr-Commit-Position: refs/heads/master@{#30139}
      a904b569
  23. 15 Jul, 2015 1 commit
  24. 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
  25. 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
  26. 03 Jun, 2015 1 commit
  27. 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
  28. 01 Jun, 2015 1 commit
  29. 11 Apr, 2015 1 commit
  30. 09 Apr, 2015 1 commit