1. 22 Jun, 2021 1 commit
  2. 18 Jun, 2021 1 commit
  3. 16 Mar, 2021 1 commit
  4. 14 Jan, 2021 1 commit
  5. 09 Nov, 2020 1 commit
  6. 15 Oct, 2020 2 commits
  7. 08 Oct, 2020 2 commits
  8. 07 Oct, 2020 1 commit
  9. 30 Sep, 2020 2 commits
    • Clemens Backes's avatar
      [wasm] Add a "boolean validation" mode · 43f0f49d
      Clemens Backes authored
      All instantiations of the function body decoder (validation, Liftoff,
      TurboFan) currently generate precise error messages. For Liftoff though,
      the error message and location is never used. Thus we can save some
      binary size and performance by only keeping a flag whether an error
      occured or not. In the error case, the TurboFan compiler will execute
      right afterwards anyway, generating a proper error message.
      
      As as follow-up, we can avoid storing the pc in {ValueBase} and
      {ControlBase}, because that's only used for error reporting.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10969
      Change-Id: I65c46cb9d8b654f9476f2c34ca9a8dd45d6bbbc5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2436347
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70235}
      43f0f49d
    • Clemens Backes's avatar
      [wasm] Rename {ValidateFlag} constants · 2a71b320
      Clemens Backes authored
      As a preparation to add a "boolean validation" mode, rename the existing
      flags. This removes many unrelated changes from the follow-up change and
      makes it easier to review.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10969
      Change-Id: I5f71405b525a7caa91be46c035e31d4d960e4e4c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440036Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70224}
      2a71b320
  10. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm][memory64] Start implementing the memory64 proposal · 18da0875
      Clemens Backes authored
      This is a first small step for implementing the memory64 proposal:
      1. Add a feature flag.
      2. Add the 0x04 and 0x05 limits flag for memory64.
      3. Read memory limits as LEB-encoded u64 (instead of u32) if a memory64
         limit flag was read.
      4. Unify {MaximumFlag} and {MemoryFlag}, which was used inconsistently
         before.
      5. Add test for memory limits encoded with >5 bytes.
      6. Move some macros from module-decoder-unittest.cc to wasm-macro-gen.h.
      
      Note that still the same limits for the maximum number of pages applies
      as before, i.e. you cannot specify a memory >4GB yet. But you can encode
      that small number in >5 bytes.
      
      R=manoskouk@chromium.org
      
      Bug: v8:10949
      Change-Id: I90a4f08426ae714a67440281785eb00cfc24a349
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2423712
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70110}
      18da0875
  11. 01 Jul, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm] Properly implement parsing of s33 values · 5df74c35
      Manos Koukoutos authored
      Motivation:
      We used to approximate s33/i33 value parsing by first checking for
      specific negative codes, and then parsing an u32 value if that failed.
      This is not correct in all cases.
      
      Changes:
      - Implement i33 parsing in Decoder.
      - Factor out parsing of heap types into read_heap_type.
      - Introduce HeapType::kBottom.
      - Introduce helper functions in WasmFeatures and value_type_reader.
      - Remove macros from the parsing of value types.
      - HeapType::code now returns an i32 for compatibility with the i33
        requirement.
      - Introduce HeapType::Repr.
      - Renamings: HeapType::type() -> representation(),
                   ValueType::heap() -> heap_representation()
      
      Bug: v8:7748
      Change-Id: I04deabce8837a48af2226411cd706a397f9e5725
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2274118
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68633}
      5df74c35
  12. 24 Jun, 2020 2 commits
  13. 24 Apr, 2020 1 commit
  14. 17 Apr, 2020 1 commit
  15. 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
  16. 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
  17. 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
  18. 30 Oct, 2019 1 commit
  19. 16 Oct, 2019 1 commit
  20. 21 Jun, 2019 1 commit
  21. 24 May, 2019 1 commit
  22. 23 May, 2019 1 commit
  23. 21 May, 2019 1 commit
  24. 15 May, 2019 1 commit
  25. 29 Apr, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
  26. 29 Mar, 2019 1 commit
  27. 14 Mar, 2019 1 commit
  28. 26 Feb, 2019 2 commits
  29. 28 Jan, 2019 1 commit
  30. 15 Jan, 2019 1 commit
  31. 30 Nov, 2018 1 commit
  32. 29 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Pass offset instead of pc to error functions · fd7d6b8b
      Clemens Hammacher authored
      This adds error functions that receive offsets instead of pc, since the
      streaming compiler stores different sections in different buffers, so
      computing pointer differences between different sections does not work.
      We keep the pc-based methods for now to reduce code-churn and
      complexity at the different call sites.
      
      R=ahaas@chromium.org
      CC=binji@chromium.org
      
      Bug: v8:8238
      Change-Id: I1aa68740bdda93c3341431aa7a81ac01ecfb71bb
      Reviewed-on: https://chromium-review.googlesource.com/c/1354463Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57944}
      fd7d6b8b
  33. 22 Oct, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Turn Result methods into named constructors · 5edf567a
      Clemens Hammacher authored
      This removes the {error} and {verror} methods of {ResultBase} and
      introduces a named constructor {Error} instead. This allows to
      construct an error result in a single expression, and moves {Result}
      closer to a container that is initialized once and is immutable
      afterwards (just the {MoveErrorFrom} method is still violating this
      pattern).
      
      R=titzer@chromium.org
      
      Bug: v8:8238
      Change-Id: Iec16c8c6d66300ee82a48e8a9e941c72ae26e202
      Reviewed-on: https://chromium-review.googlesource.com/c/1293370
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56857}
      5edf567a
  34. 19 Oct, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Move error reporting out of FinishCompilation · e32daf0a
      Clemens Hammacher authored
      And remove the TurboFan/Liftoff specific {FinishCompilation}
      implementations completely. Compilation errors are now stored in the
      {WasmCompilationUnit} directly as a {Result<WasmCode*>}. They are
      retrieved via {WasmCompilationUnit::ReportError}, which moves the error
      to the {ErrorThrower}.
      This prepares more changes to completely remove the {FinishCompilation}
      phase.
      
      R=titzer@chromium.org
      
      Bug: v8:7921
      Change-Id: I4f9a6e919359aeab074880d0d38211500b76e4ec
      Reviewed-on: https://chromium-review.googlesource.com/c/1290975
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56826}
      e32daf0a