1. 04 Jul, 2018 1 commit
  2. 25 Jun, 2018 1 commit
  3. 20 Jun, 2018 1 commit
  4. 19 Jun, 2018 1 commit
  5. 14 Jun, 2018 2 commits
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored
      This is a reland of 0909dbe3.
      Added missing V8_EXPORT_PRIVATE to AndroidLogStream.
      
      TBR=mstarzinger@chromium.org
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      >
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      >
      > R=mstarzinger@chromium.org
      >
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      Bug: v8:7820
      Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
      Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored
      This reverts commit 0909dbe3.
      
      Reason for revert: Blocks roll:
      https://chromium-review.googlesource.com/c/chromium/src/+/1099143
      
      Original change's description:
      > Introduce StdoutStream which prints to Android log or stdout
      > 
      > The often used construct {OFStream(stdout)} does not work on Android.
      > This CL introduces an {StdoutStream} which behaves exactly like
      > {OFStream(stdout)} on non-android platforms, and redirects to the
      > Android log on appropriate systems and configurations.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Bug: v8:7820
      > Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
      > Reviewed-on: https://chromium-review.googlesource.com/1088911
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#53692}
      
      TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org
      
      Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7820
      Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  6. 13 Jun, 2018 1 commit
  7. 12 Jun, 2018 1 commit
  8. 06 Jun, 2018 1 commit
  9. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  10. 15 Mar, 2018 1 commit
  11. 13 Feb, 2018 1 commit
    • Mike Stanton's avatar
      [turbofan] Masking/poisoning in codegen (optimized code, x64) · 8f489e73
      Mike Stanton authored
      This introduces masking of loads with speculation bit during code generation.
      At the moment, this is done only for x64 optimized code, under the
      --branch-load-poisoning flag.
      
      Overview of changes:
      - new register configuration configuration with one register reserved for
        the speculation poison/mask (kSpeculationPoisonRegister).
      - in codegen, we introduce an update to the poison register at the starts
        of all successors of branches (and deopts) that are marked as safety
        branches (deopts).
      - in memory optimizer, we lower all field and element loads to PoisonedLoads.
      - poisoned loads are then masked in codegen with the poison register.
        * only integer loads are masked at the moment.
      
      Bug: chromium:798964
      Change-Id: Ie51fdbde578fc289dff029794f3cfe8eaf33e1ef
      Reviewed-on: https://chromium-review.googlesource.com/901625
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#51272}
      8f489e73
  12. 30 Jan, 2018 1 commit
    • Pierre Langlois's avatar
      [turbofan] Refactor AssembleMove and AssembleSwap · 16f2bcdb
      Pierre Langlois authored
      The way the code generator's AssembleMove and AssembleSwap methods are written
      makes it easy to forget which sort of move is being implemented when looking at
      a sequence of instructions. This patch is an attempt to address this by
      rewriting those methods using switch/case instead of a string of if/else.
      
      To do this, introduce new utility functions to detect what type of move to
      perform given a pair of InstructionOperands.
      
      Bug: 
      Change-Id: I32b146c86409e595b7b59a66bf43220899024fdd
      Reviewed-on: https://chromium-review.googlesource.com/749201
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50966}
      16f2bcdb
  13. 13 Dec, 2017 1 commit
  14. 25 Sep, 2017 1 commit
  15. 04 Aug, 2017 1 commit
  16. 03 Aug, 2017 1 commit
  17. 14 Jul, 2017 1 commit
  18. 13 Jul, 2017 1 commit
  19. 30 Jun, 2017 1 commit
  20. 08 Jun, 2017 1 commit
    • bbudge's avatar
      [WASM] Eliminate SIMD boolean vector types. · 381f7da0
      bbudge authored
      - Eliminates b1x4, b1x8, and b1x16 as distinct WASM types.
      - All vector comparisons return v128 type.
      - Eliminates b1xN and, or, xor, not.
      - Selects take a v128 mask vector and are now bit-wise.
      - Adds a new test for Select, where mask is non-canonical (not 0's and -1's).
      
      LOG=N
      BUG=v8:6020
      
      Review-Url: https://codereview.chromium.org/2919203002
      Cr-Commit-Position: refs/heads/master@{#45795}
      381f7da0
  21. 22 May, 2017 1 commit
  22. 23 Feb, 2017 1 commit
  23. 21 Feb, 2017 1 commit
    • bbudge's avatar
      [V8] Implement SIMD Boolean vector types to allow mask registers. · 9fe0b4c7
      bbudge authored
      - Adds new machine types SimdBool4/8/16 for the different boolean vector types.
      - Adds a kSimdMaskRegisters flag for each platform. These are all false for now.
      - Removes Create, ExtractLane, ReplaceLane, Equal, NotEqual, Swizzle and Shuffle
        opcodes from the Boolean types. These are unlikely to be well supported natively,
        and can be synthesized using Select.
      - Changes the signature of Relational opcodes to return boolean vectors.
      - Changes the signature of Select opcodes to take boolean vectors.
      - Updates the ARM implementation of Relational and Select opcodes.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2700813002
      Cr-Commit-Position: refs/heads/master@{#43348}
      9fe0b4c7
  24. 10 Feb, 2017 1 commit
  25. 09 Feb, 2017 2 commits
  26. 23 Dec, 2016 1 commit
    • ivica.bogosavljevic's avatar
      MIPS: Reland of `Fix bad RegisterConfiguration usage in InstructionSequence unit tests` · c42bbec9
      ivica.bogosavljevic authored
      Reland 0cf56232
      
      The original patch got reverted because testing RegisterConfiguration was
      overwritten by turbofan RegisterConfiguration. This caused some test cases not being
      properly tested. The new patch uses correct RegisterConfiguration.
      
      Original commit message:
      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=
      
      Review-Url: https://codereview.chromium.org/2595293002
      Cr-Commit-Position: refs/heads/master@{#41938}
      c42bbec9
  27. 16 Dec, 2016 1 commit
    • 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
  28. 15 Dec, 2016 1 commit
    • ahaas's avatar
      [wasm] Introduce the TrapIf and TrapUnless operators to generate trap code. · 7bd61b60
      ahaas authored
      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
      
      Review-Url: https://codereview.chromium.org/2562393002
      Cr-Commit-Position: refs/heads/master@{#41720}
      7bd61b60
  29. 09 Nov, 2016 2 commits
    • bbudge's avatar
      [Turbofan] Reduce register allocation work when we can. · 472cb045
      bbudge authored
      - Track representations of virtual registers in InstructionSequence.
      - Skip extra aliasing work when no floats or SIMD registers are used.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2468233004
      Cr-Commit-Position: refs/heads/master@{#40870}
      472cb045
    • ivica.bogosavljevic's avatar
      MIPS: Fix bad RegisterConfiguration usage in InstructionSequence unit tests. · 0cf56232
      ivica.bogosavljevic authored
      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=
      
      Review-Url: https://codereview.chromium.org/2433093002
      Cr-Commit-Position: refs/heads/master@{#40862}
      0cf56232
  30. 26 Oct, 2016 1 commit
    • bbudge's avatar
      [Turbofan] Add concept of FP register aliasing on ARM 32. · 09ab8e6a
      bbudge authored
      - Modifies RegisterConfiguration to specify complex aliasing on ARM 32.
      - Modifies RegisterAllocator to consider aliasing.
      - Modifies ParallelMove::PrepareInsertAfter to handle aliasing.
      - Modifies GapResolver to split wider register moves when interference
      with smaller moves is detected.
      - Modifies MoveOptimizer to handle aliasing.
      - Adds ARM 32 macro-assembler pseudo move instructions to handle cases where
        split moves don't correspond to actual s-registers.
      - Modifies CodeGenerator::AssembleMove and AssembleSwap to handle moves of
        different widths, and moves involving pseudo-s-registers.
      - Adds unit tests for FP operand interference checking and PrepareInsertAfter.
      - Adds more tests of FP for the move optimizer and register allocator.
      
      LOG=N
      BUG=v8:4124
      
      Review-Url: https://codereview.chromium.org/2410673002
      Cr-Commit-Position: refs/heads/master@{#40597}
      09ab8e6a
  31. 11 Oct, 2016 1 commit
    • mtrofin's avatar
      [turbofan] Avoid large deopt blocks · 33629651
      mtrofin authored
      Treat allocation of splintered ranges differently, by optimizing for move
      counts (i.e. try to have less move counts), rather than optimizing for
      quality of moves (which is what normal allocation does).
      
      We can see reductions in code size in the benchmarks that measure it
      (e.g. Unity)
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2347563004
      Cr-Commit-Position: refs/heads/master@{#40178}
      33629651
  32. 19 Sep, 2016 1 commit
  33. 06 Sep, 2016 1 commit
  34. 01 Sep, 2016 1 commit
  35. 16 Aug, 2016 1 commit
  36. 29 Jul, 2016 1 commit
  37. 18 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Add support for eager/soft deoptimization reasons. · db635d5b
      bmeurer authored
      So far TurboFan wasn't adding the deoptimization reasons for eager/soft
      deoptimization exits that can be used by either the DevTools profiler or
      the --trace-deopt flag. This adds basic support for deopt reasons on
      Deoptimize, DeoptimizeIf and DeoptimizeUnless nodes and threads through
      the reasons to the code generation.
      
      Also moves the DeoptReason to it's own file (to resolve include cycles)
      and drops unused reasons.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2161543002
      Cr-Commit-Position: refs/heads/master@{#37823}
      db635d5b