Skip to content

V
V8
Switch branch/tag
  1. 19 Mar, 2020 12 commits
    • Andreas Haas's avatar
      [wasm] Introduce a WasmTableInit CSA builtin · ca5ee9d6
      Andreas Haas authored 
      This CL introduces a CSA builtin for the TableInit instruction. This
builtin allows to generate smaller code for both TurboFan and Liftoff,
and easier code generation from Liftoff.

The smaller code size comes from:
* Parameters are passed through registers, not the stack.
* Lower number of parameters: the call target, number of parameters, and
context are not passed as parameters.
* No int to smi conversion in generated code.

The CL also introduces a small CSA function which takes an uint32 value
and a max value as parameters and returns a Smi of the minimum of these
two.

R=clemensb@chromium.org, ishell@chromium.org

Bug: v8:10281
Change-Id: I40f248c20ec76e6ae9483a5e2907a68f42f2cb04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106201
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66792}
      ca5ee9d6
    • Clemens Backes's avatar
      [liftoff] Add some more code comments · 599a6e0a
      Clemens Backes authored 
      Add some more code comments for code snippets that are not obvious,
especially if debug code is enabled.
The comments help when looking at Liftoff code for debugging code
generation issues.

R=thibaudm@chromium.org

Change-Id: I566bf2b05a454fb8addc030359969d36cb2cb707
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108557Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66791}
      599a6e0a
    • Clemens Backes's avatar
      [liftoff][debug] Minor cleanup · a1439d41
      Clemens Backes authored 
      1) Replace a condition by a DCHECK.
2) Remove dead argument.

R=thibaudm@chromium.org

Bug: v8:10321
Change-Id: I546d18e7e5520630ab32b4f73f9fe12b0441cb95
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108556Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66790}
      a1439d41
    • Clemens Backes's avatar
      [liftoff][debug] Implement StepIn · da647667
      Clemens Backes authored 
      Update the "hook on function call" flag also in the wasm case, and
slightly change the {IsStepping} logic to stop in any frame if the last
step action was anything other than StepNext.
In future CLs, this has to be extended further for StepOut and for
StepOver at a return location.
When that is done, we can also reenable more stepping in the test.

R=thibaudm@chromium.org

Bug: v8:10321
Change-Id: Ib3aa8c2c2e137690140e5879a33e2bcc340821e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108035
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66789}
      da647667
    • Daniel Bevenius's avatar
      [torque] Use char newline character instead of string · 32b22fe9
      Daniel Bevenius authored 
      Currently, when GeneratePrintDefinitionsForClass generates its Print
functions it uses a string literal as the newline character for all the
last lines. For example:

void TorqueGeneratedStruct<Struct, HeapObject>::StructPrint(
    std::ostream& os) {
  this->PrintHeader(os, "TorqueGeneratedStruct");
  os << "\n";
}

The last line could use a single character instead of a string,
for example:

void TorqueGeneratedStruct<Struct, HeapObject>::StructPrint(
    std::ostream& os) {
  this->PrintHeader(os, "TorqueGeneratedStruct");
  os << '\n';
}

The commit suggests changing this into a char.

Change-Id: Id7a2f5fb17108fcbb543109d18b6b474ac1c5d2d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108546Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66788}
      32b22fe9
    • Philip Pfaffe's avatar
      [wasm-debug-evaluate] Implement the foundation for wasm debug evaluate · 96966950
      Philip Pfaffe authored 
      This implements the first part of WebAssembly debug evaluate. The patch
includes the foundation required to execute evaluator modules. It only
implements the first of the APIs of the evaluator module spec.

Bug: chromium:1020120
Change-Id: I06ec98a63d0a0ec8d81c2eac4319c4b85d3e16c1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089936
Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66787}
      96966950
    • Leszek Swirski's avatar
      Revert "[regexp] Rewrite error handling" · 2193f691
      Leszek Swirski authored 
      This reverts commit e80ca24c.

Reason for revert: Causes failures in the fast/regex/non-pattern-characters.html Blink web test (https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3679)

Original change's description:
> [regexp] Rewrite error handling
> 
> This patch modifies irregexp's error handling. Instead of representing
> errors as C strings, they are represented as an enumeration value
> (RegExpError), and only converted to strings when throwing the error
> object in regexp.cc. This makes it significantly easier to integrate
> into SpiderMonkey. A few notes:
> 
> 1. Depending on whether the stack overflows during parsing or
>    analysis, the stack overflow message can vary ("Stack overflow" or
>    "Maximum call stack size exceeded"). I kept that behaviour in this
>    patch, under the assumption that stack overflow messages are
>    (sadly) the sorts of things that real world code ends up depending
>    on.
> 
> 2. Depending on the point in code where the error was identified,
>    invalid unicode escapes could be reported as "Invalid Unicode
>    escape", "Invalid unicode escape", or "Invalid Unicode escape
>    sequence". I fervently hope that nobody depends on the specific
>    wording of a syntax error, so I standardized on the first one. (It
>    was both the most common, and the most consistent with other
>    "Invalid X escape" messages.)
> 
> 3. In addition to changing the representation, this patch also adds an
>    error_pos field to RegExpParser and RegExpCompileData, which stores
>    the position at which an error occurred. This is used by
>    SpiderMonkey to provide more helpful messages about where a syntax
>    error occurred in large regular expressions.
> 
> 4. This model is closer to V8's existing MessageTemplate
>    infrastructure. I considered trying to integrate it more closely
>    with MessageTemplate, but since one of our stated goals for this
>    project was to make it easier to use irregexp outside of V8, I
>    decided to hold off.
> 
> R=​jgruber@chromium.org
> 
> Bug: v8:10303
> Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66784}

TBR=jgruber@chromium.org,iireland@mozilla.com

Change-Id: I9247635f3c5b17c943b9c4abaf82ebe7b2de165e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10303
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108550Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66786}
      2193f691
    • Emanuel Ziegler's avatar
      [wasm][mips] Save FP & PC when calling C functions · 38c3bd48
      Emanuel Ziegler authored 
      Ported changes from the following CLs to mips/mips64:
  - https://chromium-review.googlesource.com/c/v8/v8/+/2066964
  - https://chromium-review.googlesource.com/c/v8/v8/+/2071866
  - https://chromium-review.googlesource.com/c/v8/v8/+/2080242

This change is needed for profiling of Wasm code that calls C-function
to ignore the C-stack above the Wasm stack that otherwise couldn't be
parsed otherwise.

Bug: chromium:1045860
Change-Id: Ifdce5be6c5373714a67b3ce8d8c4f0a18f63b6fa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2082566Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66785}
      38c3bd48
    • Iain Ireland's avatar
      [regexp] Rewrite error handling · e80ca24c
      Iain Ireland authored 
      This patch modifies irregexp's error handling. Instead of representing
errors as C strings, they are represented as an enumeration value
(RegExpError), and only converted to strings when throwing the error
object in regexp.cc. This makes it significantly easier to integrate
into SpiderMonkey. A few notes:

1. Depending on whether the stack overflows during parsing or
   analysis, the stack overflow message can vary ("Stack overflow" or
   "Maximum call stack size exceeded"). I kept that behaviour in this
   patch, under the assumption that stack overflow messages are
   (sadly) the sorts of things that real world code ends up depending
   on.

2. Depending on the point in code where the error was identified,
   invalid unicode escapes could be reported as "Invalid Unicode
   escape", "Invalid unicode escape", or "Invalid Unicode escape
   sequence". I fervently hope that nobody depends on the specific
   wording of a syntax error, so I standardized on the first one. (It
   was both the most common, and the most consistent with other
   "Invalid X escape" messages.)

3. In addition to changing the representation, this patch also adds an
   error_pos field to RegExpParser and RegExpCompileData, which stores
   the position at which an error occurred. This is used by
   SpiderMonkey to provide more helpful messages about where a syntax
   error occurred in large regular expressions.

4. This model is closer to V8's existing MessageTemplate
   infrastructure. I considered trying to integrate it more closely
   with MessageTemplate, but since one of our stated goals for this
   project was to make it easier to use irregexp outside of V8, I
   decided to hold off.

R=jgruber@chromium.org

Bug: v8:10303
Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66784}
      e80ca24c
    • Leszek Swirski's avatar
      Revert "[parser] Introduce UnoptimizedCompileFlags" · fabea6af
      Leszek Swirski authored 
      This reverts commit d91679bf.

Reason for revert: Seems to cause UBSan errors

Original change's description:
> [parser] Introduce UnoptimizedCompileFlags
> 
> UnoptimizedCompileFlags defines the input flags shared between parse and
> compile (currently parse-only). It is set initially with some values, and
> is immutable after being passed to ParseInfo (ParseInfo still has getters
> for the fields, but no setters).
> 
> Since a few of the existing flags were output flags, ParseInfo now has a
> new output_flags field, which will eventually migrate to a ParseOutputs
> structure.
> 
> Bug: v8:10314
> Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66782}

TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org

Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10314
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66783}
      fabea6af
    • Leszek Swirski's avatar
      [parser] Introduce UnoptimizedCompileFlags · d91679bf
      Leszek Swirski authored 
      UnoptimizedCompileFlags defines the input flags shared between parse and
compile (currently parse-only). It is set initially with some values, and
is immutable after being passed to ParseInfo (ParseInfo still has getters
for the fields, but no setters).

Since a few of the existing flags were output flags, ParseInfo now has a
new output_flags field, which will eventually migrate to a ParseOutputs
structure.

Bug: v8:10314
Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66782}
      d91679bf
    • v8-ci-autoroll-builder's avatar
      Update V8 DEPS. · 2b1d9b0f
      v8-ci-autoroll-builder authored 
      Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/44de6a6..9b1394c

Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/42d02fb..8413a03

Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/a30b7bd..464e9ff

TBR=machenbach@chromium.org,tmrts@chromium.org

Change-Id: Ibfb16f9a6ca42a16fa40f6534d77bbe6e4ef5c39
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109202Reviewed-by: 's avatarv8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#66781}
      2b1d9b0f
  3. 18 Mar, 2020 25 commits
  5. 17 Mar, 2020 3 commits