Skip to content

V
V8
Switch branch/tag
  1. 12 Mar, 2020 10 commits
  3. 11 Mar, 2020 18 commits
  5. 10 Mar, 2020 12 commits
    • Ng Zhi An's avatar
      [wasm-simd][liftoff][arm][arm64] I32x4 I16x8 F32x4 add · f63189d6
      Ng Zhi An authored 
      Bug: v8:9909
Change-Id: Ic309d394620ec17791bac2902116e15058b28a68
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091634Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66652}
      f63189d6
    • Dominik Inführ's avatar
      [heap] Report allocated size of global handles · 8d08318e
      Dominik Inführ authored 
      Report the allocated size of global handles in GetHeapStatistics as
well, not including free handles.

Bug: chromium:1060192
Change-Id: I1aedba36735f897cd8518edbb5ef2261cc348bff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093493
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66651}
      8d08318e
    • Richard Townsend's avatar
      [arm64][msvc] Fix the embedded snapshot writer for Windows on Arm, MSVC · 2cdbb99b
      Richard Townsend authored 
      Suffered from a confusion of masm/marmasm syntax for the x64 host and
arm64 target (could only generate one syntax or ther other). Fixed by
moving the compile-time flag to a runtime one.

Bug: v8:10012

Change-Id: I34746a495b1881c1d0465995930979bb768b07e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1962854Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66650}
      2cdbb99b
    • Leszek Swirski's avatar
      [parser] Set script id on ParseInfo creation · b4712802
      Leszek Swirski authored 
      Rather than having an optional script id during ParseInfo creation (which
is either selected lazily on script creation, or eagerly if based on an
existing Script), always eagerly get either the desired script id (either
from the Script or Isolate::GetNextScriptId()).

This has the side-effect that we will currently no longer need to get the
script id on background threads, but I'm not reverting the thread-safety
of Isolate::GetNextScriptId in case it's needed again in the future.

Bug: v8:10314
Change-Id: I8f2dd962d3652b1a84a5d704a099e57a1679aba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096616
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66649}
      b4712802
    • Leszek Swirski's avatar
      [parser] Remove ParseInfo flag setting after script creation · e68b5941
      Leszek Swirski authored 
      Previously, ParseInfo would create a script (with CreateScript) based on
its flags, and then set its own flags based on that created script. This
created a weird circular dependency for some of those flags, and
sometimes we would have valid flags before script creation (main thread
compile), while other times not (streaming compile).

Now we set the ParseInfo flags manually and uniformly before script
creation, and check that they match the created script after it has been
created.

Bug: v8:10314
Change-Id: Ife886c77727cd228c944a4f97369a3e6365d8219
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093433
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66648}
      e68b5941
    • Victor Gomes's avatar
      [compiler] Add CallJSStub · a05ee6cb
      Victor Gomes authored 
      The arguments order in a JS stack is now controlled by
V8_REVERSE_JSARGS macro.
This CL creates two stubs that allow the order of the arguments
to be reversed without changing CallStub.

Bug: v8:10201
Change-Id: I8f70adf3ced1f45a00f5c4ddd47d5f604f2d3100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093506
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66647}
      a05ee6cb
    • Dan Elphick's avatar
      [compiler] Add runtime call stats for builtin generation · 1c922f0f
      Dan Elphick authored 
      Useful for profiling why mksnapshot is so slow in conjunction with
--runtime-call-stats.

Change-Id: Ib193d292352e0019b93c8edccb38a904aadbf553
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089932Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66646}
      1c922f0f
    • Janusz Majnert's avatar
      Make torque emit structs in classes in order · 5a04c5ce
      Janusz Majnert authored 
      Torque compiler emits a C++ class definition header
class-definitions-tq.h. Unfortunately it does so in a manner that
introduces randomness into the ordering of some structs. This means that
every full build of V8 may yield a different header.
Since this header is included in a lot of files in V8, it causes a lot
of ccache misses (over a 1000).

This commit makes sure that the structs are emitted in lexical order.

Bug: v8:10310
Change-Id: Ie39066d36e41583ff990bc639f7f241462351585
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093500
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66645}
      5a04c5ce
    • Milad Farazmand's avatar
      s390: [arm] Add missing RELATIVE_CODE_TARGET iteration · 9d3cca1c
      Milad Farazmand authored 
      Port b766299d
Port 9592b043
Port d915b8d6

Original Commit Message:

    Code object iteration was missing logic for RELATIVE_CODE_TARGET
    reloc entries. Garbage collection could thus miss objects that were
    referenced only as targets of pc-relative calls or jumps.

    RELATIVE_CODE_TARGETs are only used on arm, mips, and s390 and only
    at mksnapshot-time.

    This exposed another issue in that the interpreter entry trampoline
    copy we generate for profiling *did* contain relative calls in
    runtime-accessible code. This is a problem, since code space on arm is,
    by default, too large to be fully addressable through pc-relative
    calls. This CL thus also disables the related
    FLAG_interpreted_frames_native_stack feature on arm.

    objects.

R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Ifbcaed98d90a2730f0d6a8a7d32c621dab1ff5b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2087693Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#66644}
      9d3cca1c
    • Leszek Swirski's avatar
      [parser] Move ParseInfo wrapped argument setup · 4f3b0990
      Leszek Swirski authored 
      Change wrapped argument set-up to be closer to where it's needed: setting
up a top-level SFI, or initializing a ParseInfo from a top-level SFI.

This is a generally cleaner use of the interface, avoids splitting the
setting of the funciton syntax kind and wrapped arguments (including
checking script.is_wrapped() in two places for the same behaviour), plus
it avoids unnecessarily creating wrapped_argument handles for functions
inside a wrapped script.

As a drive-by, rename ParseInfo::SetFlagsFromScript to a clearer

ParseInfo::SetFlagsForFunctionInScript, to differentiate between flags
from a script for top-level vs. non-top-level.

Bug: v8:10314
Change-Id: Ibdaad957558c13a1528dcc3da1ba8f262f357e48
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093509
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66643}
      4f3b0990
    • Jakob Kummerow's avatar
      [gm.py] Migrate to Python 3 · 085c804f
      Jakob Kummerow authored 
      The code was almost compatible, only one small issue had snuck in.

No-try: true
Change-Id: I52225fb2092bf16a5fffbde957cd1dfe4f2c4fd6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093492Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66642}
      085c804f
    • Iain Ireland's avatar
      [regexp] Fix and unify non-unicode case-folding algorithms · 3fab9d05
      Iain Ireland authored 
      Non-unicode, case-insensitive regexps (e.g. /foo/i, not foo/iu) use a
case-folding algorithm that doesn't quite match the Unicode
definition. There are two places in irregexp that need to do
case-folding. Prior to this patch, neither of them quite matched the
spec (https://tc39.es/ecma262/#sec-runtime-semantics-canonicalize-ch).

This patch implements the "Canonicalize" algorithm in
src/regexp/special-case.h, and uses it in the relevant places. It
replaces special-case logic around upper-casing / ASCII characters
with the following approach:

1. For most characters, calling UnicodeSet::closeOver on a set
   containing that character will produce the correct set of
   case-insensitive matches.

2. For a small handful of characters (like the sharp S that prompted
   this change), UnicodeSet::closeOver will include some characters
   that should be omitted. For example, although closeOver('ß') =
   "ßẞ", uppercase('ß') is "SS", so step 3.e means that 'ß'
   canonicalizes to itself, and should not match 'ẞ'. In these cases,
   we can skip the closeOver entirely, because it will never add an
   equivalent character. These characters are in the IgnoreSet.

3. For an even smaller handful of characters, UnicodeSet::closeOver
   will produce some characters that should be omitted, but also some
   characters that should be included. For example, closeOver('k') =
   "kKK" (lowercase k, uppercase K, U+212A KELVIN SIGN), but KELVIN
   SIGN should not match either of the other two (step 3.g). To handle
   this, we put such characters in the SpecialAddSet. In these cases,
   we closeOver the original character, but filter out the results
   that do not have the same canonical value.

The computation of IgnoreSet and SpecialAddSet happens at build time,
using the pre-existing gen-regexp-special-case.cc step.

R=jgruber@chromium.org

Bug: v8:10248
Change-Id: I00d48b180c83bb8e645cc59eda57b01eab134f0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2072858Reviewed-by: 's avatarFrank Tang <ftang@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66641}
      3fab9d05