Skip to content

V
V8
Switch branch/tag
  1. 02 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Disallow nullptr modules in decoder · 6b633af7
      Clemens Backes authored 
      In production, we will always pass a pointer to the decoded module. The
only reason for the existance of the nullptr checks is that tests
sometimes don't pass a module here. Hence we pay in production code for
a test-only feature.

This CL fixes this by always passing a module pointer from the decoder
tests. This even simplifies the code a lot by removing redundant code.

The {TestModuleBuilder} class was moved before the definitions of the
{FunctionBodyDecoderTest} class in order to be able to reuse it there.
It's unmodified otherwise.

R=ahaas@chromium.org

Bug: v8:10576
Change-Id: I7d876bfc8a27b50fe713afb8848fb4f642287cfa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2226749Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68116}
      6b633af7
  3. 29 May, 2020 1 commit
  5. 20 May, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Make StreamingDecoder abstract, introduce AsyncStreamingDecoder · 6921a490
      Andreas Haas authored 
      The implementation of the StreamingDecoder depends on async compilation.
However, when the --single-threaded flag is set, async compilation is
not available. Therefore V8 does not support streaming compilation at
the moment if the --single-threaded flag is set.

This CL is the first step to support streaming compilation in
--single-threaded mode. This CL makes the StreamingDecoder an abstract
class, and the current implementation a sub-class called
AsyncStreamingDecoder. A follow-up CL will provided a second sub-class
implementation for streaming compilation in --single-threaded mode.

Bug: v8:10548
Change-Id: Ice5c01340d3df18f836a4a05d30571207ca8ccf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208869
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67931}
      6921a490
  7. 18 May, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm] Refactor/cleanup DecodeLocals, read_value_type · a4d295ad
      Manos Koukoutos authored 
      Changes:
Cleanup:
- Make sure read_value_type has the same interface as other
  read_* functions, i.e., returns the decoded value and writes
  the consumed length into a pointer.
- DecodeLocals is now an instance method.
- DecodeLocals should fail when given a wrong number of locals.
  Add tests to catch that.
- Fix a buggy test.

Refactoring in preparation of introducing the 'let'
instruction as per [wasm-gc]:
- DecodeLocals does not consume any input and can start from any pc.
- DecodeLocals gives the option of not appending the decoded
  locals to local_types_.
- Separate locals initialization from signature.

Bug: v8:7748
Change-Id: Iaaff87fdb9abe0ddd716484ea3fa87779d2d1a2f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2202992
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67845}
      a4d295ad
  9. 06 May, 2020 1 commit
  11. 05 May, 2020 1 commit
  13. 30 Apr, 2020 1 commit
  15. 22 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Fix performance bottleneck in DisjointAllocationPool · 7e0279fa
      Clemens Backes authored 
      When compiling modules with many functions, the list of regions in the
{DisjointAllocationPool} can become quite large if the functions die in
a random order (which they typically do, since the order of Liftoff
compilation is different than the order to TurboFan compilation; which
work stealing, both are nondeterministic).
Iterating the list of regions in the {DisjointAllocationPool} was thus
linear in the number of regions, which is linear in the number of
functions of the module. Since we insert new regions one by one, overall
runtime was quadratic.

This CL fixes this by switching from a linked list to a std::set.
Merging a new region is thus logarithmic instead of linear, and overall
we are {n*log(n)} instead of {n^2}.

Note: For {AllocateInRegion} we still need to linearly iterate all
regions that overlap the requested region, but this has not shown to be
a problem so far.

R=ahaas@chromium.org

Bug: v8:10432
Change-Id: I193e56c2abab782e386194fbe64dadfa250916f7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154797
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67303}
      7e0279fa
  17. 20 Apr, 2020 1 commit
  19. 17 Apr, 2020 3 commits
  21. 16 Apr, 2020 1 commit
    • Ng Zhi An's avatar
      [wasm] Fix wasm decoder for multi-byte opcodes · b48b82e7
      Ng Zhi An authored 
      SIMD opcodes consist of the prefix byte, then an LEB128 encoded int. We
were decoding this incorrectly as a fixed uint8. This fixes the decoder
to properly handle multi bytes.

In some cases, the multi byte logic is applied to all prefixed opcodes.
This is not a problem, since for values < 0x80, the LEB encoding is a
single byte, and decodes to the same int. If the prefix opcode has
instructions with index >= 0x80, it would be required to be LEB128
encoded anyway.

There are a bunch of trivial changes to test-run-wasm-simd, to change
the macro from BUILD to BUILD_V, the former only works for single byte
opcodes, the latter is a new template-based macro that correct handles
multi-byte opcodes. The only unchanged test is the shuffle fuzzer test,
which builds its own sequence of bytes without using the BUILD macro.

Bug: v8:10258
Change-Id: Ie7377e899a7eab97ecf28176fd908babc08d0f19
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118476
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67186}
      b48b82e7
  23. 23 Mar, 2020 1 commit
  25. 12 Mar, 2020 1 commit
  27. 27 Feb, 2020 1 commit
  29. 26 Feb, 2020 1 commit
  31. 25 Feb, 2020 1 commit
    • Andreas Haas's avatar
      Reland "[wasm] The name of a custom section can cause a validation error" · 7a318130
      Andreas Haas authored 
      This is a reland of 03d5a7ba

Nothing changed here compared to the original test. The tests on the
blink side were invalid, I fixed them in https://crrev.com/c/2066907.

Original change's description:
> [wasm] The name of a custom section can cause a validation error
>
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
>
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
>
> R=clemensb@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}

Bug: v8:10126
Change-Id: I48aaed8eb9899da1703030fb6809fe46a6e66191
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2069325
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66431}
      7a318130
  33. 19 Feb, 2020 2 commits
    • Michael Achenbach's avatar
      Revert "[wasm] The name of a custom section can cause a validation error" · 43accc8b
      Michael Achenbach authored 
      This reverts commit 03d5a7ba.

Reason for revert: Needs rebaseline:
https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/3243

Original change's description:
> [wasm] The name of a custom section can cause a validation error
> 
> The WebAssembly spec defines that the name of a custom section can cause
> a validation error. The streaming decoder, however, used a separate
> Decoder object to decode the name, and thereby avoided a validation
> error. With this CL the streaming decoder uses the main decoder to
> decode the name of the custom section.
> 
> In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
> This test defined an invalid WebAssembly module and expected it to
> compile. As it is a regression test, it makes no sense to fix the test.
> The module is invalid because it defines the length of the custom section
> to be '0', so there are no bytes in the custom section for its name.
> 
> R=​clemensb@chromium.org
> CC=​thibaudm@chromium.org
> 
> Bug: v8:10126
> Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66348}

TBR=ahaas@chromium.org,clemensb@chromium.org

Change-Id: I5a7ea265ce47b9e685a5056bb83db6dc58f774a9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10126
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2065168Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66356}
      43accc8b
    • Andreas Haas's avatar
      [wasm] The name of a custom section can cause a validation error · 03d5a7ba
      Andreas Haas authored 
      The WebAssembly spec defines that the name of a custom section can cause
a validation error. The streaming decoder, however, used a separate
Decoder object to decode the name, and thereby avoided a validation
error. With this CL the streaming decoder uses the main decoder to
decode the name of the custom section.

In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
This test defined an invalid WebAssembly module and expected it to
compile. As it is a regression test, it makes no sense to fix the test.
The module is invalid because it defines the length of the custom section
to be '0', so there are no bytes in the custom section for its name.

R=clemensb@chromium.org
CC=thibaudm@chromium.org

Bug: v8:10126
Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66348}
      03d5a7ba
  35. 17 Feb, 2020 1 commit
  37. 23 Jan, 2020 1 commit
  39. 17 Jan, 2020 1 commit
  41. 15 Jan, 2020 1 commit
  43. 08 Jan, 2020 1 commit
  45. 06 Dec, 2019 1 commit
  47. 05 Dec, 2019 1 commit
  49. 28 Nov, 2019 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up WASM_CALL_INDIRECT macros · a183b8be
      Clemens Backes authored 
      Fix a TODO from Ben to change the macro argument order to match the
actual order in wasm code.
After this fix, we can remove the individual {WASM_CALL_INDIRECT[0-5]}
macros and implement them via a common variadic macro.

Also, rename {WASM_CALL_INDIRECT_TABLE0} to {WASM_CALL_INDIRECT_TABLE}.
The name was confusing, because this macro explictly allows to set a
table index different from 0. Thus, just drop the "0" in the name.

The individual test changes were done via a vim macro, to avoid manual
errors.

R=mstarzinger@chromium.org

Bug: v8:10021
Change-Id: I9f0f31511c5c6e20a0b07524bf75fe9cf1598eba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1940265Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65242}
      a183b8be
  51. 26 Nov, 2019 2 commits
  53. 14 Nov, 2019 1 commit
  55. 08 Nov, 2019 2 commits
  57. 31 Oct, 2019 1 commit
  59. 30 Oct, 2019 1 commit
  61. 08 Oct, 2019 2 commits
  63. 01 Oct, 2019 1 commit
  65. 26 Sep, 2019 1 commit
  67. 24 Sep, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Fix TODO and remove bad tests · ae764cc3
      Clemens Hammacher authored 
      In the {Fixed} variant, the {WasmCodeManagerTest} always reserves
1GB of memory. This makes the test run OOM on many 32-bit platforms.
Instead of skipping it selectively, this CL just removes the whole
test. It caused a lot of trouble in the past, and needs two test-only
methods in the WasmCodeManager. Also, the {Fixed} variant will not be
needed any more with the wasm far jump table, since modules can always
grow then.

Drive-by: Clean up the unittests status file a bit.

R=mstarzinger@chromium.org

Bug: v8:9477
Change-Id: I5b6f8ed9f800863575c69d49d5df82f21fd23030
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1815251Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes [né Hammacher] <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63942}
      ae764cc3