1. 19 Dec, 2016 29 commits
  2. 18 Dec, 2016 2 commits
  3. 17 Dec, 2016 4 commits
  4. 16 Dec, 2016 5 commits
    • mtrofin's avatar
      Revert of MIPS: Fix bad RegisterConfiguration usage in InstructionSequence... · 8e833623
      mtrofin authored
      Revert of MIPS: Fix bad RegisterConfiguration usage in InstructionSequence unit tests. (patchset #3 id:40001 of https://codereview.chromium.org/2433093002/ )
      
      Reason for revert:
      This change rendered InstructionSequenceTest::SetNumRegs ineffectual, thus
      loosening the tests that were using that API to ensure correct register
      allocation under intentionally constrained setups.
      
      For the problem stated in this CL, a solution needs to continue supporting the
      intentionally set-up test configuration.
      
      Original issue's description:
      > MIPS: Fix bad RegisterConfiguration usage in InstructionSequence unit tests.
      >
      > Test InstructionSequenceTest has been initialized with a testing RegisterConfiguration
      > instance defined in instruction-sequence-unittest.h, whereas class ExplicitOperand which
      > is being tested used RegisterConfiguration from instruction.cc. In case these two
      > instances are different, the tests would fail. The issue is fixed by using the same
      > instance of RegisterConfiguration both for test code and code under test.
      >
      > Additionally, the tests in register-allocator-unittest.cc use hardcoded values
      > for register and begin failing is the hardcoded register is not available for
      > allocation. Fix by forcing the use of allocatable registers only.
      >
      > TEST=unittests.MoveOptimizerTest.RemovesRedundantExplicit,unittests.RegisterAllocatorTest.SpillPhi
      > BUG=
      >
      > Committed: https://crrev.com/0cf56232209d4c9c669b8426680de18806f6c29a
      > Cr-Commit-Position: refs/heads/master@{#40862}
      
      TBR=dcarney@chromium.org,bmeurer@chromium.org,mstarzinger@chromium.org,vogelheim@chromium.org,titzer@chromium.org,ivica.bogosavljevic@imgtec.com
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      BUG=
      
      Review-Url: https://codereview.chromium.org/2587593002
      Cr-Commit-Position: refs/heads/master@{#41777}
      8e833623
    • littledan's avatar
      Remove class fields desugaring · 61833f5b
      littledan authored
      This patch removes parser code implementing desugaring for ESnext
      public and private fields on classes. The desugaring should probably
      be implemented in the interpreter instead, and more work needs to go
      into optimization and debugger support. The actual parsing of class
      fields is left in, as the syntax is relatively stable, and there are
      strong cctests for the grammar.
      
      R=marja
      BUG=v8:5367
      
      Review-Url: https://codereview.chromium.org/2578893005
      Cr-Commit-Position: refs/heads/master@{#41776}
      61833f5b
    • gsathya's avatar
      [promisehook] Implement PromiseHook · b1c148b9
      gsathya authored
      This adds kInit, kResolve, kBefore and kAfter lifecycle hooks to promises.
      
      This also exposes an API to set the PromiseHook.
      
      BUG=v8:4643
      
      Review-Url: https://codereview.chromium.org/2575313002
      Cr-Commit-Position: refs/heads/master@{#41775}
      b1c148b9
    • ahaas's avatar
      [wasm] TrapIf and TrapUnless TurboFan operators implemented on arm. · ca8d3ba7
      ahaas authored
      Original commit message:
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code.
      
      Some instructions in WebAssembly trap for some inputs, which means that the
      execution is terminated and (at least at the moment) a JavaScript exception is
      thrown. Examples for traps are out-of-bounds memory accesses, or integer
      divisions by zero.
      
      Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
      TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
      constant), in addition to the trap condition itself. Additionally, each
      WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
      number of inputs is linear to the number of trap checks in the function.
      Especially for functions with high numbers of trap checks we observe a
      significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
      benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
      a TrapIf common operator only a single node is necessary per trap check, in
      addition to the trap condition. Also the nodes which are shared between trap
      checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
      speedup of 30-50% on average.
      
      This CL only implements TrapIf and TrapUnless on x64. The implementation is also
      hidden behind the --wasm-trap-if flag.
      
      Please take a special look at how the source position is transfered from the
      instruction selector to the code generator, and at the context that is used for
      the runtime call.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com
      
      Review-Url: https://codereview.chromium.org/2584603002
      Cr-Commit-Position: refs/heads/master@{#41774}
      ca8d3ba7
    • ulan's avatar
      [heap] Reland "Use RAIL mode for initial heap sizing". · 7bdb9069
      ulan authored
      The original patch was reverted because of performance
      regressions caused by removal of old heap sizing heuristics.
      
      This patch keeps the old heuristics and adds RAIL mode.
      
      BUG=chromium:613518
      
      Review-Url: https://codereview.chromium.org/2576543002
      Cr-Commit-Position: refs/heads/master@{#41773}
      7bdb9069