1. 13 Jul, 2020 1 commit
  2. 23 Dec, 2019 1 commit
  3. 19 Dec, 2019 1 commit
  4. 17 Dec, 2019 1 commit
    • Zhang, Shiyu's avatar
      Reland "Support Intel VTune ITT API" · 0b812b72
      Zhang, Shiyu authored
      This is a reland of 5f5b4b04
      
      Original change's description:
      > Support Intel VTune ITT API
      > 
      > Add VTune domain support extension to use VTune Domain/Task API and
      > tagging trace data for particular JS code block.
      > 
      > How to use:
      > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
      > file to download intel/ittapi by 'gclient sync'
      > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
      > 3. Run d8 with flag '--enable-vtune-domain-support'
      > 
      > The Vtune Domain/Task API can be invoked from JS to mark JS code block.
      > You can mark the start of a JS task by
      >     vtunedomainmark(domain_name, task_name, "start")
      > and the end of a task by
      >     vtunedomainmark(domain_name, task_name, "end")
      > Tasks can nest.
      > 
      > The VTune API (ittapi) is integrated as an external third party library
      > while the v8_vtune_jit also relies on the VTune ittapi. We have another
      > patch almost ready which refactors the v8_vtune_jit related code to
      > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
      > code after this patch stabilized and landed.
      > 
      > 
      > Contributed by fanchen.kong@intel.com
      > 
      > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
      > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65409}
      
      Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65478}
      0b812b72
  5. 11 Dec, 2019 2 commits
    • Maya Lekova's avatar
      Revert "Support Intel VTune ITT API" · d8053c9a
      Maya Lekova authored
      This reverts commit 5f5b4b04.
      
      Reason for revert: Breaks vtunejit bot - see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20vtunejit/32958
      
      Original change's description:
      > Support Intel VTune ITT API
      > 
      > Add VTune domain support extension to use VTune Domain/Task API and
      > tagging trace data for particular JS code block.
      > 
      > How to use:
      > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
      > file to download intel/ittapi by 'gclient sync'
      > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
      > 3. Run d8 with flag '--enable-vtune-domain-support'
      > 
      > The Vtune Domain/Task API can be invoked from JS to mark JS code block.
      > You can mark the start of a JS task by
      >     vtunedomainmark(domain_name, task_name, "start")
      > and the end of a task by
      >     vtunedomainmark(domain_name, task_name, "end")
      > Tasks can nest.
      > 
      > The VTune API (ittapi) is integrated as an external third party library
      > while the v8_vtune_jit also relies on the VTune ittapi. We have another
      > patch almost ready which refactors the v8_vtune_jit related code to
      > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
      > code after this patch stabilized and landed.
      > 
      > 
      > Contributed by fanchen.kong@intel.com
      > 
      > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
      > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65409}
      
      TBR=machenbach@chromium.org,hpayer@chromium.org,verwaest@chromium.org,shiyu.zhang@intel.com
      
      Change-Id: I44a6e5b1aa32e753ae41966ed321ed787cc752f8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960291Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65410}
      d8053c9a
    • Zhang, Shiyu's avatar
      Support Intel VTune ITT API · 5f5b4b04
      Zhang, Shiyu authored
      Add VTune domain support extension to use VTune Domain/Task API and
      tagging trace data for particular JS code block.
      
      How to use:
      1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient
      file to download intel/ittapi by 'gclient sync'
      2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true'
      3. Run d8 with flag '--enable-vtune-domain-support'
      
      The Vtune Domain/Task API can be invoked from JS to mark JS code block.
      You can mark the start of a JS task by
          vtunedomainmark(domain_name, task_name, "start")
      and the end of a task by
          vtunedomainmark(domain_name, task_name, "end")
      Tasks can nest.
      
      The VTune API (ittapi) is integrated as an external third party library
      while the v8_vtune_jit also relies on the VTune ittapi. We have another
      patch almost ready which refactors the v8_vtune_jit related code to
      depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit
      code after this patch stabilized and landed.
      
      
      Contributed by fanchen.kong@intel.com
      
      Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490
      Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65409}
      5f5b4b04
  6. 31 Oct, 2019 1 commit
  7. 17 Oct, 2019 1 commit
    • Zhou, Zhiguo's avatar
      Log debug info of WASM for Intel VTune Amplifier · ec580709
      Zhou, Zhiguo authored
      This CL logs debug information of WASM in Intel VTune Amplifer via
      VTune's JIT Profiling API. With this CL, the profiling information
      of JITted code and its corresponding C/C++ source code is displayed
      optionally. To use this feature, a runtime flag "vtune_prof_annotat
      e_wasm" should be passed to the VTune-enabled V8 engine. Currently,
      the inline function in C/C++ is not well supported due to the
      limitation of source map.
      
      As a drive-by fix, the dynamically allocated event-specific data
      of JavaScript (src/third_party/vtune/vtune-jit.cc) is managed with
      C++ containers for safety.
      
      Change-Id: Ic27420fcdcd775bc5c7778abf5cff6edf0fb38b6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782126Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com>
      Cr-Commit-Position: refs/heads/master@{#64351}
      ec580709
  8. 12 Aug, 2019 1 commit
  9. 31 May, 2019 1 commit
  10. 30 May, 2019 1 commit
  11. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  12. 24 Apr, 2019 1 commit
  13. 04 Apr, 2019 1 commit
  14. 09 Jan, 2019 1 commit
  15. 08 Aug, 2018 1 commit
  16. 23 Jul, 2018 1 commit
  17. 16 Jul, 2018 1 commit
  18. 28 Mar, 2018 1 commit
  19. 23 Jan, 2018 1 commit
  20. 11 Dec, 2017 1 commit
    • Justin Ridgewell's avatar
      Implement DFA Unicode Decoder · cedec225
      Justin Ridgewell authored
      This is a separation of the DFA Unicode Decoder from
      https://chromium-review.googlesource.com/c/v8/v8/+/789560
      
      I attempted to make the DFA's table a bit more explicit in this CL. Still, the
      linter prevents me from letting me present the array as a "table" in source
      code. For a better representation, please refer to
      https://docs.google.com/spreadsheets/d/1L9STtkmWs-A7HdK5ZmZ-wPZ_VBjQ3-Jj_xN9c6_hLKA
      
      - - - - -
      
      Now for a big copy-paste from 789560:
      
      Essentially, reworks a standard FSM (imagine an
      array of structs) and flattens it out into a single-dimension array.
      Using Table 3-7 of the Unicode 10.0.0 standard (page 126 of
      http://www.unicode.org/versions/Unicode10.0.0/ch03.pdf), we can nicely
      map all bytes into one of 12 character classes:
      
      00. 0x00-0x7F
      01. 0x80-0x8F (split from general continuation because this range is not
          valid after a 0xF0 leading byte)
      02. 0x90-0x9F (split from general continuation because this range is not
          valid after a 0xE0 nor a 0xF4 leading byte)
      03. 0xA0-0xBF (the rest of the continuation range)
      04. 0xC0-0xC1, 0xF5-0xFF (the joined range of invalid bytes, notice this
          includes 255 which we use as a known bad byte during hex-to-int
              decoding)
      05. 0xC2-0xDF (leading bytes which require any continuation byte
          afterwards)
      06. 0xE0 (leading byte which requires a 0xA0-0xBF afterwards then any
          continuation byte after that)
      07. 0xE1-0xEC, 0xEE-0xEF (leading bytes which requires any continuation
          afterwards then any continuation byte after that)
      08. 0xED (leading byte which requires a 0x80-0x9F afterwards then any
          continuation byte after that)
      09. 0xF1-F3 (leading bytes which requires any continuation byte
          afterwards then any continuation byte then any continuation byte)
      10. 0xF0 (leading bytes which requires a 0x90-0xBF afterwards then any
          continuation byte then any continuation byte)
      11. 0xF4 (leading bytes which requires a 0x80-0x8F afterwards then any
          continuation byte then any continuation byte)
      
      Note that 0xF0 and 0xF1-0xF3 were swapped so that fewer bytes were
      needed to represent the transition state ("9, 10, 10, 10" vs.
      "10, 9, 9, 9").
      
      Using these 12 classes as "transitions", we can map from one state to
      the next. Each state is defined as some multiple of 12, so that we're
      always starting at the 0th column of each row of the FSM. From each
      state, we add the transition and get a index of the new row the FSM is
      entering.
      
      If at any point we encounter a bad byte, the state + bad-byte-transition
      is guaranteed to map us into the first row of the FSM (which contains no
      valid exiting transitions).
      
      The key differences from Björn's original (or his self-modified) DFA is
      the "bad" state is now mapped to 0 (or the first row of the FSM) instead
      of 12 (the second row). This saves ~50 bytes when gzipping, and also
      speeds up determining if a string is properly encoded (see his sample
      code at http://bjoern.hoehrmann.de/utf-8/decoder/dfa/#performance).
      
      Finally, I've replace his ternary check with an array access, to make
      the algorithm branchless. This places a requirement on the caller to 0
      out the code point between successful decodings, which it could always
      have done because it's already branching.
      
      R=marja@google.com
      
      Bug: 
      Change-Id: I574f208a84dc5d06caba17127b0d41f7ce1a3395
      Reviewed-on: https://chromium-review.googlesource.com/805357
      Commit-Queue: Justin Ridgewell <jridgewell@google.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50012}
      cedec225
  21. 02 Aug, 2017 1 commit
  22. 13 Feb, 2017 1 commit
  23. 05 Jul, 2016 1 commit
  24. 30 Jun, 2016 1 commit
  25. 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
  26. 17 Jun, 2016 3 commits
  27. 16 Jun, 2016 3 commits
  28. 13 Jun, 2016 1 commit
    • 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
  29. 03 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Math.log to TurboFan. · f2da19fe
      bmeurer authored
      Introduce a dedicated Float64Log machine operator, that is either
      implemented by a direct C call or by platform specific code, i.e.
      using the FPU on x64 and ia32.
      
      This operator is used to implement Math.log as a proper TurboFan
      builtin on top of the CodeStubAssembler.
      
      Also introduce a NumberLog simplified operator on top of Float64Log
      and use that for the fast inline path of Math.log inside TurboFan
      optimized code.
      
      BUG=v8:5065
      
      Review-Url: https://codereview.chromium.org/2029413005
      Cr-Commit-Position: refs/heads/master@{#36703}
      f2da19fe
  30. 02 May, 2016 1 commit
  31. 30 Apr, 2016 2 commits
  32. 29 Apr, 2016 1 commit
  33. 25 Apr, 2016 1 commit
    • machenbach's avatar
      [build] Prepare moving v8.gyp to src/ · cb855fe7
      machenbach authored
      This will allow to pull in gyp as a deps to the same location
      as chromium (tools/gyp not build/gyp), needed for gn switch.
      
      This is the first step of a 3-way move.
      1) Copy v8.gyp in v8
      2) Update references in embedders (follow up)
      3) Remove old v8.gyp (follow up)
      
      BUG=chromium:474921
      LOG=n
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1920793002
      
      Cr-Commit-Position: refs/heads/master@{#35760}
      cb855fe7
  34. 09 Dec, 2015 1 commit