1. 14 Aug, 2018 1 commit
  2. 10 Aug, 2018 1 commit
  3. 09 Aug, 2018 3 commits
    • Junliang Yan's avatar
      s390: [wasm] Support 4GiB memories in Liftoff · 195f2f2a
      Junliang Yan authored
      Port 352e408b
      
      Original Commit Message:
      
          Add codegen support for up to 4GiB memories in Liftoff code.
      
          This CL also adds three new mjsunit tests that stress large WASM
          memories (1, 2, and 4 GiB) and checks that accesses near these
          boundaries properly generate traps.
      
          Note there is still some trickiness around the setting of:
            1.) the flag --wasm-max-mem-pages
            2.) wasm-limits.h kSpecMaxWasmMemoryPages = 65536
            3.) wasm-limits.h kV8MaxWasmMemoryPages = 32767
      
          In particular, the allocation of memories is still limited to
          3.) and the runtime flag can only lower this limit.
      
          The above means that the tests for 2GiB and 4GiB memories will silently
          OOM by design until 3.) is changed (though they currently pass with
          manual testing). I argue it is better to include these tests up front,
          since they will immediately trigger if their memory allocation succeeds.
      
          Therefore the plan is to lift the restriction on 3.) after removing
          all other other internal V8 limitations including array buffers and views.
      
      R=titzer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:7881
      LOG=N
      
      Change-Id: Ice70a9ac5a9a26b08cc77acb7deec98305574d01
      Reviewed-on: https://chromium-review.googlesource.com/1167914
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55026}
      195f2f2a
    • Ben L. Titzer's avatar
      [wasm] Add WasmFeatures to enable/detect features · 6aa2a253
      Ben L. Titzer authored
      This CL introduces a set of configuration options implemented as
      a struct of booleans that together comprise the set of enabled
      or detected features. The configuration options replace command-line
      flags that were checked deep in the implementation. As such, it is
      necessary to plumb them through multiple levels of abstraction.
      
      R=ahaas@chromium.org
      CC=mstarzinger@chromium.org
      BUG=chromium:868844
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
      Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55018}
      6aa2a253
    • Clemens Hammacher's avatar
      [Liftoff][cleanup][x64] Remove unused parameter · 32e4540b
      Clemens Hammacher authored
      R=titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: I2adb5a74cfdc6ec7e229f1ca1bd31d8209156617
      Reviewed-on: https://chromium-review.googlesource.com/1167519Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55002}
      32e4540b
  4. 02 Aug, 2018 1 commit
    • Ben L. Titzer's avatar
      [cleanup] Remove redundant wasm:: namespace prefixes · 99de47f1
      Ben L. Titzer authored
      The wasm/ directory is inconsistent in many places, often within the
      same file. For all code that exists in a v8::internal::wasm namespace,
      this CL removes any wasm:: qualifiers, which is especially helpful
      since most types are already Wasm-named, such as WasmCode, WasmModule,
      etc. Namespace qualifiers are redundant inside the wasm:: namespace and
      thus go against the main point of using namespaces. Removing the
      qualifiers for non Wasm-named classes also makes the code somewhat more
      future-proof, should we move some things that are not really WASM-specific
      (such as ErrorThrower and Decoder) into a higher namespace.
      
      R=clemensh@chromium.org,mstarzinger@chromium.org
      
      Change-Id: Ibff3e1e93c64c12dcb53c46c03d1bfb2fb0b7586
      Reviewed-on: https://chromium-review.googlesource.com/1160232
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54862}
      99de47f1
  5. 27 Jul, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Support 4GiB memories in Liftoff · 352e408b
      Ben L. Titzer authored
      Add codegen support for up to 4GiB memories in Liftoff code.
      
      This CL also adds three new mjsunit tests that stress large WASM
      memories (1, 2, and 4 GiB) and checks that accesses near these
      boundaries properly generate traps.
      
      Note there is still some trickiness around the setting of:
        1.) the flag --wasm-max-mem-pages
        2.) wasm-limits.h kSpecMaxWasmMemoryPages = 65536
        3.) wasm-limits.h kV8MaxWasmMemoryPages = 32767
      
      In particular, the allocation of memories is still limited to
      3.) and the runtime flag can only lower this limit.
      
      The above means that the tests for 2GiB and 4GiB memories will silently
      OOM by design until 3.) is changed (though they currently pass with
      manual testing). I argue it is better to include these tests up front,
      since they will immediately trigger if their memory allocation succeeds.
      
      Therefore the plan is to lift the restriction on 3.) after removing
      all other other internal V8 limitations including array buffers and views.
      
      R=clemensh@chromium.org
      CC=mstarzinger@chromium.org
      BUG=v8:7881
      
      Change-Id: I3205ac2daf5c9a84364c670a2c3ef2258e5649f6
      Reviewed-on: https://chromium-review.googlesource.com/1151309
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54754}
      352e408b
  6. 26 Jul, 2018 1 commit
  7. 25 Jul, 2018 4 commits
  8. 24 Jul, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored
      This is a reland of a462a785
      
      Original change's description:
      > [turboassembler] Introduce hard-abort mode
      > 
      > For checks and assertions (mostly for debug code, like stack alignment
      > or zero extension), we had two modes: Emit a call to the {Abort}
      > runtime function (the default), and emit a debug break (used for
      > testing, enabled via --trap-on-abort).
      > In wasm, where we cannot just call a runtime function because code must
      > be isolate independent, we always used the trap-on-abort behaviour.
      > This causes problems for our fuzzers, which do not catch SIGTRAP, and
      > hence do not detect debug code failures.
      > 
      > This CL introduces a third mode ("hard abort"), which calls a C
      > function via {ExternalReference}. The C function still outputs the
      > abort reason, but does not print the stack trace. It then aborts via
      > "OS::Abort", just like the runtime function.
      > This will allow fuzzers to detect the crash and even find a nice error
      > message.
      > 
      > Even though this looks like a lot of code churn, it is actually not.
      > Most added lines are new tests, and other changes are minimal.
      > 
      > R=mstarzinger@chromium.org
      > 
      > Bug: chromium:863799
      > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      > Reviewed-on: https://chromium-review.googlesource.com/1142163
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54592}
      
      Bug: chromium:863799
      Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
      Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e
  9. 20 Jul, 2018 2 commits
    • Sigurd Schneider's avatar
      Speculatively revert "[turboassembler] Introduce hard-abort mode" · 039c18e1
      Sigurd Schneider authored
      This reverts commit a462a785.
      
      Reason for revert: Breaks a TurboAssembler test:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726
      
      Original change's description:
      > [turboassembler] Introduce hard-abort mode
      > 
      > For checks and assertions (mostly for debug code, like stack alignment
      > or zero extension), we had two modes: Emit a call to the {Abort}
      > runtime function (the default), and emit a debug break (used for
      > testing, enabled via --trap-on-abort).
      > In wasm, where we cannot just call a runtime function because code must
      > be isolate independent, we always used the trap-on-abort behaviour.
      > This causes problems for our fuzzers, which do not catch SIGTRAP, and
      > hence do not detect debug code failures.
      > 
      > This CL introduces a third mode ("hard abort"), which calls a C
      > function via {ExternalReference}. The C function still outputs the
      > abort reason, but does not print the stack trace. It then aborts via
      > "OS::Abort", just like the runtime function.
      > This will allow fuzzers to detect the crash and even find a nice error
      > message.
      > 
      > Even though this looks like a lot of code churn, it is actually not.
      > Most added lines are new tests, and other changes are minimal.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: chromium:863799
      > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      > Reviewed-on: https://chromium-review.googlesource.com/1142163
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#54592}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:863799
      Reviewed-on: https://chromium-review.googlesource.com/1145431
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54597}
      039c18e1
    • Clemens Hammacher's avatar
      [turboassembler] Introduce hard-abort mode · a462a785
      Clemens Hammacher authored
      For checks and assertions (mostly for debug code, like stack alignment
      or zero extension), we had two modes: Emit a call to the {Abort}
      runtime function (the default), and emit a debug break (used for
      testing, enabled via --trap-on-abort).
      In wasm, where we cannot just call a runtime function because code must
      be isolate independent, we always used the trap-on-abort behaviour.
      This causes problems for our fuzzers, which do not catch SIGTRAP, and
      hence do not detect debug code failures.
      
      This CL introduces a third mode ("hard abort"), which calls a C
      function via {ExternalReference}. The C function still outputs the
      abort reason, but does not print the stack trace. It then aborts via
      "OS::Abort", just like the runtime function.
      This will allow fuzzers to detect the crash and even find a nice error
      message.
      
      Even though this looks like a lot of code churn, it is actually not.
      Most added lines are new tests, and other changes are minimal.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:863799
      Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
      Reviewed-on: https://chromium-review.googlesource.com/1142163
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54592}
      a462a785
  10. 17 Jul, 2018 1 commit
  11. 16 Jul, 2018 1 commit
  12. 13 Jul, 2018 4 commits
  13. 06 Jul, 2018 1 commit
  14. 05 Jul, 2018 2 commits
  15. 03 Jul, 2018 6 commits
  16. 02 Jul, 2018 1 commit
  17. 28 Jun, 2018 2 commits
  18. 27 Jun, 2018 2 commits
    • 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
    • Clemens Hammacher's avatar
      Add stream helper to output any iterable collection · ab350c16
      Clemens Hammacher authored
      {PrintCollection} can print any collection which is iterable via a
      standard for-each loop in C++. The output format of {4, 7, 11} is:
      [4, 7, 11]
      
      This helper avoids a few repetitions of manually outputting such
      collections.
      
      R=titzer@chromium.org
      
      Bug: v8:7754
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Iaa91e5465968a029815b3aa2b35948f711956cdb
      Reviewed-on: https://chromium-review.googlesource.com/1112005
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54048}
      ab350c16
  19. 25 Jun, 2018 1 commit
  20. 22 Jun, 2018 4 commits
    • Clemens Hammacher's avatar
      Reland "[Liftoff] Fix register use count" · 7f851cd4
      Clemens Hammacher authored
      This is a reland of ada64800, fixed
      for 32 bit architectures (register pairs).
      
      Original change's description:
      > [Liftoff] Fix register use count
      >
      > In {SetLocalFromStackSlot}, we decrement the use count of the register
      > in the target slot without updating this slot, and then call
      > {GetUnusedRegister}. At that point, the register use counts do not
      > match the cache state, which leads to errors later on.
      > This CL fixes this by marking the target slot as a stack slot after
      > reducing the register use count.
      >
      > It also adds a Validation which helped to find that error and will
      > catch similar errors earlier.
      >
      > R=titzer@chromium.org
      >
      > Bug: chromium:854050, v8:6600
      > Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
      > Reviewed-on: https://chromium-review.googlesource.com/1111958
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53976}
      
      TBR=titzer@chromium.org
      
      Bug: chromium:854050, v8:6600
      Change-Id: Ibc8801737e9604a8490382c569b0378585625376
      Reviewed-on: https://chromium-review.googlesource.com/1112238
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53981}
      7f851cd4
    • Clemens Hammacher's avatar
      Revert "[Liftoff] Fix register use count" · cf2f6a57
      Clemens Hammacher authored
      This reverts commit ada64800.
      
      Reason for revert: Failure with slow dchecks: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/20982
      
      Original change's description:
      > [Liftoff] Fix register use count
      > 
      > In {SetLocalFromStackSlot}, we decrement the use count of the register
      > in the target slot without updating this slot, and then call
      > {GetUnusedRegister}. At that point, the register use counts do not
      > match the cache state, which leads to errors later on.
      > This CL fixes this by marking the target slot as a stack slot after
      > reducing the register use count.
      > 
      > It also adds a Validation which helped to find that error and will
      > catch similar errors earlier.
      > 
      > R=​titzer@chromium.org
      > 
      > Bug: chromium:854050, v8:6600
      > Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
      > Reviewed-on: https://chromium-review.googlesource.com/1111958
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53976}
      
      TBR=titzer@chromium.org,clemensh@chromium.org
      
      Change-Id: I5b8d8d405dcd7f82ee431cba290419425b9859a1
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:854050, v8:6600
      Reviewed-on: https://chromium-review.googlesource.com/1112277Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53979}
      cf2f6a57
    • Clemens Hammacher's avatar
      [Liftoff] Fix register use count · ada64800
      Clemens Hammacher authored
      In {SetLocalFromStackSlot}, we decrement the use count of the register
      in the target slot without updating this slot, and then call
      {GetUnusedRegister}. At that point, the register use counts do not
      match the cache state, which leads to errors later on.
      This CL fixes this by marking the target slot as a stack slot after
      reducing the register use count.
      
      It also adds a Validation which helped to find that error and will
      catch similar errors earlier.
      
      R=titzer@chromium.org
      
      Bug: chromium:854050, v8:6600
      Change-Id: I74d3a5aa947ec4247d7b4557567f642bf4082316
      Reviewed-on: https://chromium-review.googlesource.com/1111958Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53976}
      ada64800
    • Clemens Hammacher's avatar
      [Liftoff] Inline {DropStackSlot} method · c31cf146
      Clemens Hammacher authored
      The method does not do much, and all callers actually overwrite or
      delete the stack slot right after calling this method anyways, so there
      is no need to make the slot a stack slot first.
      
      R=titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: I4fd54d2ed5f86a3e011ddc2748833dc81052ef5b
      Reviewed-on: https://chromium-review.googlesource.com/1111848Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53975}
      c31cf146