1. 25 Jun, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Implement correct type checking for br_table · c476508b
      Andreas Haas authored
      This CL refactors the type-checking for br_table instructions.
      Originally, we iterated over all targets of br_table and checked
      if the values on the stack match the types expected by the
      target's signature. However, this caused problems with type
      checking unreachable br_table instructions where some stack
      values are unavailable. According to the anyref proposal, the
      expected type of br_table is the greatest lower bound of
      all its targets. With the existing implementation, the expected
      types were the types of the first target.
      
      With this CL, we first calculate the expected types of br_table,
      and only then inspect the stack if matching values are available.
      
      R=titzer@chromium.org
      
      Bug: v8:7581
      Change-Id: I12208323bda88c363e28ffb0e002d59ef9a6b9d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1649791
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62354}
      c476508b
  2. 29 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [Liftoff] List unsupported opcodes explicitly · cbc35298
      Clemens Hammacher authored
      This removes two default switch cases for unsupported opcodes, and
      replaces them by explicit lists. This makes it easy to see what is
      currently not supported in Liftoff. In a follow-up CL, each bailout
      will be associated with a category to track which features currently
      cause Liftoff to bailout.
      This change also makes Liftoff crash (in UNREACHABLE) if invoked with
      asm.js code. Hence, change the asm.js tests to not test Liftoff. In
      production, we do not invoke Liftoff for asm.js anyway.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I971c6146ed325103d14008c0e67a973a47a35bc2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1634909
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61911}
      cbc35298
  3. 28 May, 2019 1 commit
  4. 23 May, 2019 2 commits
  5. 22 May, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Cache export wrappers per signature · d56ee2e3
      Andreas Haas authored
      Up until now, we cached export wrappers per export index. With the
      anyref proposal potentially many more functions will need export
      wrappers, e.g. any function that is stored in a table, and any
      function accessed by the new ref.func instruction.
      
      With this CL, we change the caching scheme an do the caching per
      signature. Thereby we can guarantee that any export wrapper which
      potentially exists can be stored in the cache.
      
      For cctests which use wasm-run-utils, we don't know the size of the
      cache anymore ahead of time. However, we assume that no more than
      5 signatures will be used in any cctest. If this assumption is not
      true, we can just adjust the number.
      
      The cache is now accessed in all code paths where we need an export
      wrapper.
      
      Bug: chromium:962850
      
      Change-Id: I32df60dfa7801d1e71f7d837da091f388198af1f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1615247
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61752}
      d56ee2e3
  6. 21 May, 2019 1 commit
  7. 17 May, 2019 1 commit
  8. 16 May, 2019 2 commits
  9. 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
  10. 11 Apr, 2019 1 commit
  11. 05 Apr, 2019 1 commit
  12. 03 Apr, 2019 1 commit
  13. 21 Mar, 2019 1 commit
    • Ben Smith's avatar
      [wasm] Call through dispatch table in interpreter · 1a88414c
      Ben Smith authored
      When running wasm tests, the interpreter previously used a static
      collection of function indexes stored in WasmTable to perform
      call_indirect calls internal to that module. This has the wrong behavior
      if the table is changed (via WasmTableObject::Set, `table.copy`, or
      `table.init`).
      
      This CL changes the cctests to always generate an intepreter entry for
      all functions, and stores those entries in the dispatch table. This
      allows us to use the same execution path as for non-testing code.
      
      The interpreter entry compiler needed to be changed to support
      multi-value returns too, since a 64-bit integer return value may be
      lowered to two 32-bit integer returns.
      
      Bug: v8:9016
      Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60380}
      1a88414c
  14. 20 Mar, 2019 1 commit
    • Clemens Hammacher's avatar
      [wasm] Split adding code from publishing it · 25d8a157
      Clemens Hammacher authored
      This prepares a refactoring to add and publish compilation results in
      batches. For this, we need to separate the two phases, so that we can
      lock the module, allocate all the code space, release the lock, copy
      the code, lock the module, publish the code, and release the lock
      again.
      In particular, this CL does the following:
      1) It removes the {AddOwnedCode} method. The functionality of creating
         the {WasmCode} and memcpy'ing the instruction into that is done in
         the other {Add*Code} methods. Adding to {owned_code_} is done in
         {PublishCode}.
      2) {PublishInterpreterEntry} is now functionally equivalent to
         {PublishCode}, so it's removed.
      3) After {AddCode}, the caller has to call {PublishCode}. In a
         follow-up CL, this will be called in batches (first {AddCode} them
         all, then {PublishCode} them all).
      4) {AddCompiledCode} now assumes that the {WasmCompilationResult}
         succeeded. Otherwise, the caller should directly call {SetError} on
         the {CompilationState}.
      5) {PublishCode} is now the chokepoint for installing code to the code
         table, the owned code vector, the jump table, and setting interpreter
         redirections. It replaces previous direct calls to {InstallCode} or
         explicitly adding to {owned_code_}.
      6) Increasing the {generated_code_size_} counter is now done in
         {AllocateForCode}, which is the chokepoint for allocating space for
         generated code. This way, we will only increase this counter once
         once we allocate in batches.
      
      R=titzer@chromium.org
      
      Bug: v8:8916
      Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60369}
      25d8a157
  15. 07 Mar, 2019 1 commit
  16. 27 Feb, 2019 1 commit
  17. 04 Feb, 2019 1 commit
  18. 01 Feb, 2019 1 commit
    • Clemens Hammacher's avatar
      [test] Modernize value helpers · f0d69fc9
      Clemens Hammacher authored
      This CL changes the usage pattern from
      FOR_XXX_VALUES(i) { Use(*i); }
      to
      FOR_XXX_VALUES(i) { Use(i); }
      which is way more intuitive.
      
      Note that the replacement in the uses was done via regular expression,
      so it's purely mechanical. In two locations I removed unneeded braces
      around the macro, because they confused clang-format.
      I plan to do more cleanups (remove redundant assignments within the
      FOR_XXX_VALUES body) in a follow-up CL.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8562
      Change-Id: I4329bfcf34e5b077d19b50f4204ceb3b4340fe61
      Reviewed-on: https://chromium-review.googlesource.com/c/1449615
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59287}
      f0d69fc9
  19. 28 Jan, 2019 2 commits
  20. 25 Jan, 2019 1 commit
    • Andreas Haas's avatar
      [wasm][anyref] Support anyref stack parameters · 258371bd
      Andreas Haas authored
      Anyref parameters can exist across GC runs. Therefore the GC has to
      know where anyref parameters are on the stack so that it can mark them
      in its marking phase, and update them in the compaction phase.
      
      Already in a previous CL we grouped all anyref parameters so that they
      can be found more easily in a stack frame, see
      https://crrev.com/c/1371827. In this CL we implement the stack scanning
      itself.
      
      Note that anyref parameters are not scanned while iterating over the
      caller's frame (to which they actually belong), but while iterating
      over the callee's frame. The reason is that with tail-calls, only the
      callee knows how many tagged stack parameters (aka anyref parameters)
      there are.
      
      R=mstarzinger@chromium.org
      also-by=mstarzinger@chromium.org
      
      Bug: v8:7581
      Change-Id: I7a41ce11d06c0d420146fdb0bb8d5606f28824d7
      Reviewed-on: https://chromium-review.googlesource.com/c/1424955
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59099}
      258371bd
  21. 10 Jan, 2019 1 commit
  22. 03 Dec, 2018 1 commit
  23. 14 Nov, 2018 1 commit
  24. 21 Aug, 2018 1 commit
  25. 13 Aug, 2018 1 commit
  26. 13 Jul, 2018 1 commit
  27. 28 Jun, 2018 1 commit
  28. 27 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store protected instructions in an OwnedVector · ce2d01bc
      Clemens Hammacher authored
      We currently store the protected instructions per code object in a
      {std::unique_ptr<std::vector<ProtectedInstructionData>>}. This wastes
      memory, because it requires two heap allocations, plus the vector might
      over-allocate (and it currently does, because it is filled dynamically
      during compilation).
      This CL changes that to store the protected instructions in an
      {OwnedVector}. This requires one copy after generating the list of
      {ProtectedInstructionData} in an {std::vector} during compilation, but
      saves memory afterwards.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:856938
      Change-Id: Ie290a17dc32f27fbbfe0c000a52297181c954550
      Reviewed-on: https://chromium-review.googlesource.com/1116701Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54052}
      ce2d01bc
  29. 22 Jun, 2018 2 commits
  30. 20 Jun, 2018 1 commit
  31. 04 Jun, 2018 1 commit
  32. 18 May, 2018 1 commit
  33. 07 May, 2018 1 commit
  34. 04 May, 2018 2 commits
  35. 27 Apr, 2018 1 commit