1. 07 Nov, 2017 1 commit
  2. 31 Oct, 2017 2 commits
  3. 26 Oct, 2017 1 commit
  4. 25 Oct, 2017 1 commit
    • Anisha Rohra's avatar
      s390: Liftoff: a baseline compiler for WebAssembly · a74da818
      Anisha Rohra authored
      Port 266e803e
      
      Original Commit Message:
        This CL adds a first implementation of Liftoff, the new wasm baseline
        compiler, for x64 and ia32. It currently supports the most important
        i32 instructions and control instructions. Whenever it encounters an
        instruction it does not support yet, it aborts.
        In a subsequent CL, Liftoff will be called from the
        WasmCompilationUnit, falling back to Turbofan compilation if the
        baseline compiler bails out.
      
      R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, clemensh@chromium.org, titzer@chromium.org
      BUG=
      LOG=N
      
      Change-Id: I35ad2b0230c37f523e24aa90b637a67e5ce59083
      Reviewed-on: https://chromium-review.googlesource.com/735784Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48935}
      a74da818
  5. 23 Oct, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Liftoff: a baseline compiler for WebAssembly · 266e803e
      Clemens Hammacher authored
      This CL adds a first implementation of Liftoff, the new wasm baseline
      compiler, for x64 and ia32. It currently supports the most important
      i32 instructions and control instructions. Whenever it encounters an
      instruction it does not support yet, it aborts.
      In a subsequent CL, Liftoff will be called from the
      WasmCompilationUnit, falling back to Turbofan compilation if the
      baseline compiler bails out.
      
      R=titzer@chromium.org
      
      Bug: v8:6600
      Change-Id: Ifa78fb9d546dce72c241ff01a251dfa13cb31c1d
      Reviewed-on: https://chromium-review.googlesource.com/716480
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48832}
      266e803e
  6. 20 Oct, 2017 1 commit
  7. 19 Oct, 2017 5 commits
  8. 18 Oct, 2017 1 commit
    • Jakob Gruber's avatar
      Reland "Reland "[snapshot] Add BuiltinDeserializerAllocator"" · 4104fd90
      Jakob Gruber authored
      This is a reland of 526c31d0
      Original change's description:
      > Reland "[snapshot] Add BuiltinDeserializerAllocator"
      > 
      > This is a reland of 2b9a6d89
      > Original change's description:
      > > [snapshot] Add BuiltinDeserializerAllocator
      > > 
      > > Encapsulates special reservation / allocation behavior for builtin
      > > deserialization.
      > > 
      > > Bug: v8:6624
      > > Change-Id: Ic784ed43b607c881b356c6e535c9dbe185e1d4cd
      > > Reviewed-on: https://chromium-review.googlesource.com/716229
      > > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48638}
      > 
      > TBR=yangguo@chromium.org
      > 
      > Bug: v8:6624
      > Change-Id: I07c49263b4ef128dfe9b97d364e9a279b343aa24
      > Reviewed-on: https://chromium-review.googlesource.com/723520
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48647}
      
      TBR=yangguo@chromium.org
      
      Bug: v8:6624
      Change-Id: I4186fcf89b9fce3433a02fc864346a300b90ffb5
      Reviewed-on: https://chromium-review.googlesource.com/725439Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48666}
      4104fd90
  9. 17 Oct, 2017 6 commits
  10. 16 Oct, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Optimize Reflect.has builtin. · 4213af64
      Benedikt Meurer authored
      Port the baseline version of Reflect.has to the CodeStubAssembler and
      reuse the existing logic for HasProperty (i.e. the HasProperty builtin).
      Also inline the Reflect.has builtin into TurboFan, by adding a check
      on the target in front of a use of the JSHasProperty operator.
      Technically this additional check is not necessary, because the
      JSHasProperty operator already throws if the target is not a JSReceiver,
      but the exception message is confusing then.
      
      This improves the performance of the micro-benchmark from
      
        reflectHasPresent: 337 ms.
        reflectHasAbsent: 472 ms.
      
      to
      
        reflectHasPresent: 121 ms.
        reflectHasAbsent: 216 ms.
      
      which is a nice 2.8x improvement in the best case. It also improves the
      chai test on the web-tooling-benchmark by around 1-2%, which is roughly
      the expected win (since Reflect.has overall accounts for around 3-4%).
      
      Bug: v8:5996, v8:6936, v8:6937
      Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a
      Reviewed-on: https://chromium-review.googlesource.com/720959
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48608}
      4213af64
  11. 13 Oct, 2017 3 commits
  12. 12 Oct, 2017 1 commit
  13. 10 Oct, 2017 1 commit
  14. 02 Oct, 2017 2 commits
  15. 28 Sep, 2017 3 commits
    • Toon Verwaest's avatar
      [ic] Remove extra-ic-state and Map::code_cache · b8b25e1c
      Toon Verwaest authored
      There are only very few custom compiled IC handlers left that go in there, and for each compiled handler we only have 1 cache hit on top25; maximally saving 60ms over 33s. Additionally we'll migrate the remaining handlers to data-driven handlers anyway. Let's try to remove this code.
      
      Bug: 
      Change-Id: Ib874cc498015046a3ff67c83ea8b10b3c4eb7d0f
      Reviewed-on: https://chromium-review.googlesource.com/668409
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48201}
      b8b25e1c
    • Peter Marshall's avatar
      [cleanup] Remove List. · 690d52af
      Peter Marshall authored
      ZoneList still used List as a base class, so this CL merges the two
      classes together. We also remove unused functions in List and ZoneList.
      
      We keep the inline header but move it to src/zone/zone-list-inl.h. The
      includes that use this header are still quite tangled, but we can fix
      that later.
      
      Bug: v8:6333
      Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
      Change-Id: Ia809813834b2328ff616623f8a843812a1eb42a7
      Reviewed-on: https://chromium-review.googlesource.com/681658
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48200}
      690d52af
    • Peter Marshall's avatar
      [cleanup] Replace List with std::vector in api. · 329f6946
      Peter Marshall authored
      The members of HandleScopeImplementer are copied with memcpy when
      the isolate is transferred to another thread. List contained some
      primitives which allowed us to manually free the backing store, which
      was needed in order to ensure that threads would not hold on to
      old pointers and use them later. With std::vector, we can't do that.
      
      Here we change the HandleScopeImplementer to instead use a custom
      structure DetachableVector, which contains a std::vector but allows
      manual detaching and freeing of the backing store. This allows us to
      maintain the old behavior.
      
      Bug: v8:6333
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
      Reviewed-on: https://chromium-review.googlesource.com/660125Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48197}
      329f6946
  16. 25 Sep, 2017 1 commit
  17. 22 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [es2015] Introduce dedicated GetTemplateObject bytecode. · 79ac69b8
      Benedikt Meurer authored
      Tagged templates were previously desugared during parsing using some
      combination of runtime support written in JavaScript and C++, which
      prevented some optimizations from happening, namely the constant folding
      of the template object in TurboFan optimized code. This CL adds a new
      bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
      node), which represents the abstract operation in the ES6 specification
      and allows TurboFan to simply constant-fold template objects at compile
      time (which is explicitly supported by the specification).
      
      This also pays down some technical debt by removing the template.js
      runtime support and therefore should reduce the size of the native
      context (snapshot) a bit.
      
      With this change in-place the ES6 version microbenchmark in the
      referenced tracking bug is now faster than the transpiled Babel
      code, it goes from
      
        templateStringTagES5: 4552 ms.
        templateStringTagES6: 14185 ms.
        templateStringTagBabel: 7626 ms.
      
      to
      
        templateStringTagES5: 4515 ms.
        templateStringTagES6: 7491 ms.
        templateStringTagBabel: 7639 ms.
      
      which corresponds to a solid 45% reduction in execution time. With some
      further optimizations the ES6 version should be able to outperform the
      ES5 version. This micro-benchmark should be fairly representative of the
      six-speed-templatestringtag-es6 benchmark, and as such that benchmark
      should also improve by around 50%.
      
      Bug: v8:6819,v8:6820
      Tbr: mlippautz@chromium.org
      Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
      Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarCaitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48126}
      79ac69b8
  18. 20 Sep, 2017 1 commit
  19. 19 Sep, 2017 2 commits
  20. 16 Sep, 2017 3 commits
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] A simple allocator datastructure for off-the heap"" · 3d046986
      Mircea Trofin authored
      This reverts commit ee5c31f3.
      
      Reason for revert: Fixed compiler failure
      
      Original change's description:
      > Revert "[wasm] A simple allocator datastructure for off-the heap"
      > 
      > This reverts commit 110d9ab0.
      > 
      > Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
      > 
      > Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
      > 
      > Original change's description:
      > > [wasm] A simple allocator datastructure for off-the heap
      > > 
      > > We'll use this allocator in a follow-up CL to:
      > > - allocate speculative sizes of memory for a module that's being
      > > compiled (e.g. 2*size of wasm code).
      > > - each module will own such a sub-pool, and then use it to allocate
      > > contiguous chunks of memory for code.
      > > 
      > > The underlying assumptions for the chosen allocation strategy is that:
      > > - the allocation granularity for pools is 1 page, so that no one page
      > > is owned by more than one wasm module
      > > - typical pool sizes (given module sizes) are multiple pages.
      > > - modules and module instances are typically few and long lived. Typically,
      > > we expect one module and one instance. 
      > > 
      > > This means we shouldn't expect fragmentations that lead to code being
      > > non-allocatable, or prohibitively many ranges.
      > > 
      > > The data structure just manages ranges of addresses. Virtual memory management
      > > will be separate, as part of the responsibility of a "WasmHeap"
      > > that will be introduced in the future. So will concurrency control.
      > > 
      > > Bug: 
      > > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
      > > Reviewed-on: https://chromium-review.googlesource.com/669296
      > > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      > > Reviewed-by: Eric Holk <eholk@chromium.org>
      > > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#48053}
      > 
      > TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      > 
      > Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Reviewed-on: https://chromium-review.googlesource.com/670141
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48054}
      
      TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/670142
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48055}
      3d046986
    • Mircea Trofin's avatar
      Revert "[wasm] A simple allocator datastructure for off-the heap" · ee5c31f3
      Mircea Trofin authored
      This reverts commit 110d9ab0.
      
      Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
      
      Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
      
      Original change's description:
      > [wasm] A simple allocator datastructure for off-the heap
      > 
      > We'll use this allocator in a follow-up CL to:
      > - allocate speculative sizes of memory for a module that's being
      > compiled (e.g. 2*size of wasm code).
      > - each module will own such a sub-pool, and then use it to allocate
      > contiguous chunks of memory for code.
      > 
      > The underlying assumptions for the chosen allocation strategy is that:
      > - the allocation granularity for pools is 1 page, so that no one page
      > is owned by more than one wasm module
      > - typical pool sizes (given module sizes) are multiple pages.
      > - modules and module instances are typically few and long lived. Typically,
      > we expect one module and one instance. 
      > 
      > This means we shouldn't expect fragmentations that lead to code being
      > non-allocatable, or prohibitively many ranges.
      > 
      > The data structure just manages ranges of addresses. Virtual memory management
      > will be separate, as part of the responsibility of a "WasmHeap"
      > that will be introduced in the future. So will concurrency control.
      > 
      > Bug: 
      > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
      > Reviewed-on: https://chromium-review.googlesource.com/669296
      > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      > Reviewed-by: Eric Holk <eholk@chromium.org>
      > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48053}
      
      TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/670141Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48054}
      ee5c31f3
    • Mircea Trofin's avatar
      [wasm] A simple allocator datastructure for off-the heap · 110d9ab0
      Mircea Trofin authored
      We'll use this allocator in a follow-up CL to:
      - allocate speculative sizes of memory for a module that's being
      compiled (e.g. 2*size of wasm code).
      - each module will own such a sub-pool, and then use it to allocate
      contiguous chunks of memory for code.
      
      The underlying assumptions for the chosen allocation strategy is that:
      - the allocation granularity for pools is 1 page, so that no one page
      is owned by more than one wasm module
      - typical pool sizes (given module sizes) are multiple pages.
      - modules and module instances are typically few and long lived. Typically,
      we expect one module and one instance. 
      
      This means we shouldn't expect fragmentations that lead to code being
      non-allocatable, or prohibitively many ranges.
      
      The data structure just manages ranges of addresses. Virtual memory management
      will be separate, as part of the responsibility of a "WasmHeap"
      that will be introduced in the future. So will concurrency control.
      
      Bug: 
      Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
      Reviewed-on: https://chromium-review.googlesource.com/669296
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarBrad Nelson <bradnelson@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48053}
      110d9ab0
  21. 13 Sep, 2017 1 commit
    • Mostyn Bramley-Moore's avatar
      [jumbo] fix arm64 builds · 46000a12
      Mostyn Bramley-Moore authored
      Previously instructions-arm64.h was alternatively defining or declaring
      some constants based on whether or not ARM64_DEFINE_FP_STATICS was defined,
      and it was assumed that exactly one file would include this header with
      the macro defined.
      
      In jumbo builds, the header guards in instructions-arm64.h meant that the
      resulting state of the header file would be whichever of the two cases
      that appeared first in the compilation unit.  This would cause multiple
      definitions in some cases and no definitions in some other cases (or if
      you were really lucky, it would work out ok).
      
      Let's move these constants to a separate source file temporarily, to be
      excluded from jumbo compilation units.  This code should eventually be
      replaced with a cleaner solution.
      
      Bug: chromium:746958
      Change-Id: I7edb1821ef408afd50c6b236d63d3c07f955b58f
      Reviewed-on: https://chromium-review.googlesource.com/663898
      Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48003}
      46000a12
  22. 11 Sep, 2017 1 commit