Skip to content

V
V8
Switch branch/tag
  1. 19 Dec, 2016 30 commits
  3. 18 Dec, 2016 2 commits
  5. 17 Dec, 2016 4 commits
  7. 16 Dec, 2016 4 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