Skip to content

V
V8
Switch branch/tag
  1. 24 Nov, 2020 1 commit
  3. 09 Nov, 2020 2 commits
  5. 06 Nov, 2020 1 commit
  7. 05 Nov, 2020 1 commit
    • Zhi An Ng's avatar
      [wasm-simd][x64] Optimize integer splats of constant 0 · 7d7b25d9
      Zhi An Ng authored 
      Integer splats (especially for sizes < 32-bits) does not directly
translate to a single instruction on x64. We can do better for special
values, like 0, which can be lowered to `xor dst dst`. We do this check
in the instruction selector, and emit a special opcode kX64S128Zero.

Also change the xor operation for kX64S128Zero from xorps to pxor. This
can help reduce any potential data bypass delay (search for this on
agner's microarchitecture manual for more details.). Since integer
splats are likely to be followed by integer ops, we should remain in the
integer domain, thus use pxor.

For i64x2.splat the codegen goes from:

  xorl rdi,rdi
  vmovq xmm0,rdi
  vmovddup xmm0,xmm0

to:

  vpxor xmm0,xmm0,xmm0

Also add a unittest to verify this optimization, and necessary
raw-assembler methods for the test.

Bug: v8:11093
Change-Id: I26b092032b6e672f1d5d26e35d79578ebe591cfe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2516299Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70977}
      7d7b25d9
  9. 02 Nov, 2020 1 commit
  11. 28 Oct, 2020 3 commits
  13. 27 Oct, 2020 3 commits
  15. 13 Oct, 2020 1 commit
    • Daniel Bevenius's avatar
      [test] Suppress subobject-linkage warnings · 3705048d
      Daniel Bevenius authored 
      Currently there are a number of -Wsubobject-linkage warnings when
compiling with gcc (formatted to fit 72 character lines):

In file included from
...
from ../../testing/gtest/include/gtest/gtest.h:10,
from ../../testing/gtest-support.h:8,
from ../../test/unittests/test-utils.h:20,
from ../../test/unittests/compiler/backend/
  instruction-selector-unittest.h:15,
from ../../test/unittests/compiler/x64/
  instruction-selector-x64-unittest.cc:9:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:
In instantiation of ‘class
testing::internal::ParameterizedTestFactory<v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>’:
../../third_party/googletest/src/googletest/include/gtest/internal/
gtest-param-util.h:439:12:   required from
‘testing::internal::TestFactoryBase*
testing::internal::TestMetaFactory<TestSuite>::CreateTestFactory(
  testing::internal::TestMetaFactory<TestSuite>::ParamType)
[with
TestSuite = v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test;
testing::internal::TestMetaFactory<TestSuite>::ParamType =
  v8::internal::compiler::{anonymous}::LoadWithToInt64Extension]’
../../third_party/googletest/src/googletest/include/gtest/internal/
  gtest-param-util.h:438:20:   required from here
../../third_party/googletest/src/googletest/include/gtest/internal/
  gtest-param-util.h:394:7: warning:
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test >’ has a field
‘testing::internal::ParameterizedTestFactory<
v8::internal::compiler::
InstructionSelectorChangeInt32ToInt64Test_ \
ChangeInt32ToInt64WithLoad_Test>::parameter_’ whose type uses the
anonymous namespace [-Wsubobject-linkage]
  394 | class ParameterizedTestFactory : public TestFactoryBase {
      |       ^~~~~~~~~~~~~~~~~~~~~~~~

This commit moves the parameterized tests in question into the
anonymous namespace to avoid the warnings.

Change-Id: I9c4a8bd9f4e225ed14ab64f5433d5f5c102e01a1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2418723Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70482}
      3705048d
  17. 07 Oct, 2020 1 commit
    • Ross McIlroy's avatar
      [TurboProp] Add support for deferred block spills in fast reg alloc · 4a601911
      Ross McIlroy authored 
      Adds support for avoiding spills in non-deferred blocks by instead
restricting the spill ranges to deferred blocks if the virtual
register is only spilled in deferred blocks.

It does this by tracking registers that reach the exit point of deferred
blocks and spilling them them pre-emptively in the deferred block while
treating them as committed from the point of view of the non-deferred
blocks. We also now track whether virtual registers need to be spilled
at their SSA definition point (where they are output by an instruction),
or can instead be spilled at the entry to deferred blocks for use as
spill slots within those deferred blocks. In both cases, the tracking
of these deferred spills is kept as a pending operation until the
allocator confirms that adding these spills will avoid spills in the
non-deferred pathways, to avoid adding unnecessary extra spills in
deferred blocks.

BUG=v8:9684

Change-Id: Ib151e795567f0e4e7f95538415a8cc117d235b64
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440603
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70374}
      4a601911
  19. 01 Oct, 2020 1 commit
  21. 28 Sep, 2020 1 commit
  23. 22 Sep, 2020 1 commit
  25. 16 Sep, 2020 1 commit
  27. 11 Sep, 2020 1 commit
  29. 18 Aug, 2020 1 commit
  31. 13 Aug, 2020 1 commit
  33. 10 Aug, 2020 1 commit
  35. 31 Jul, 2020 3 commits
  37. 30 Jul, 2020 3 commits
  39. 28 Jul, 2020 2 commits
    • Ross McIlroy's avatar
      [TurboProp] Add reference map population to fast reg alloc. · e9a37bf8
      Ross McIlroy authored 
      Adds support for populating reference maps to the fast
register allocator. In order to calculate whether a stack slot
is live at a given instruction, we use the dominator tree to
build a bitmap of blocks which are dominated by each block.
A variable's spill operand is classed as alive for any blocks that are
dominated by the block it was defined in, until the instruction index
of the spill operand's last use. As such, it may be classified as live
down a branch where the spill operand is never used, however it is safe
since the spill slot won't be re-allocated until after it's last-use
instruction index in any case.

BUG=v8:9684

Change-Id: I772374599ef916f57d82d468f66429e32c712ddf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2298008
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69108}
      e9a37bf8
    • Ross McIlroy's avatar
      [TurboProp] Add support for spill slot allocation to fast reg alloc · 5b0c6cde
      Ross McIlroy authored 
      Adds support for tracking the instruction range of spilled operands,
and then allocating spill slots to these ranges. It also adds some
unittests covering spill slot allocation.

Spill slots are allocated in a linear fashion, running through the
instruction stream in a linear order, ensuring that no spill operand
is allocated to a same spill slot that is already assigned to during
this whole start / end range. This isn’t optimal, since it doesn’t
take into account holes in these ranges (e.g, blocks between start
and end that aren’t dominated by the start), but in practice rarely
leads to more than one extra spill slot being allocated compared to
the current allocator.

BUG=v8:9684

Change-Id: Iedee7bcf552080e5b4b6a2f4e96b78b6c1396cab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2297470Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69107}
      5b0c6cde
  41. 24 Jul, 2020 2 commits
  43. 22 Jul, 2020 1 commit
    • Seth Brenith's avatar
      Profile-guided optimization of builtins · 922983df
      Seth Brenith authored 
      Design doc:
https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing

V8 can already collect data about how many times each basic block in the
builtins is run. This change enables using that data for profile-guided
optimization. New comments in BUILD.gn describe how to use this feature.

A few implementation details worth mentioning, which aren't covered in
the design doc:

- BasicBlockProfilerData currently contains an array of RPO numbers.
  However, this array is always just [0, 1, 2, 3, ...], so this change
  removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
  ensures that the removal is valid.

- RPO numbers, while useful for printing data that matches with the
  stringified schedule, are not useful for matching profiling data with
  blocks that haven't been scheduled yet. This change adds a new array
  of block IDs in BasicBlockProfilerData, so that block counters can be
  used for PGO.

- Basic block counters need to be written to a file so that they can be
  provided to a subsequent run of mksnapshot, but the design doc doesn't
  specify the transfer format or what file is used. In this change, I
  propose using the existing v8.log file for that purpose. Block count
  records look like this:

  block,TestLessThanHandler,37,29405

  This line indicates that block ID 37 in TestLessThanHandler was run
  29405 times. If multiple lines refer to the same block, the reader
  adds them all together. I like this format because it's easy to use:
  - V8 already has robust logic for creating the log file, naming it to
    avoid conflicts in multi-process situations, etc.
  - Line order doesn't matter, and interleaved writes from various
    logging sources are fine, given that V8 writes each line atomically.
  - Combining multiple sources of profiling data is as simple as
    concatenating their v8.log files together.

- It is a good idea to avoid making any changes based on profiling data
  if the function being compiled doesn't match the one that was
  profiled, since it is common to use profiling data downloaded from a
  central lab which is updated only periodically. To check whether a
  function matches, I propose using a hash of the Graph state right
  before scheduling. This might be stricter than necessary, as some
  changes to the function might be small enough that the profile data is
  still relevant, but I'd rather err on the side of not making incorrect
  changes. This hash is also written to the v8.log file, in a line that
  looks like this:

  builtin_hash,LdaZeroHandler,3387822046

Bug: v8:10470
Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69008}
      922983df
  45. 14 Jul, 2020 2 commits
  47. 10 Jul, 2020 2 commits
  49. 06 Jul, 2020 3 commits