1. 30 Mar, 2022 1 commit
  2. 17 Sep, 2021 1 commit
  3. 27 Aug, 2021 1 commit
    • Ng Zhi An's avatar
      [x64] Consolidate SSE/AVX Float32/Float64 Abs/Neg · 9996d8ae
      Ng Zhi An authored
      1. Move Abspd, Negpd from MacroAssembler into TurboAssembler so that we
      can use it in code-generator
      2. Add Absps and Negps (float32 versions of the instructions in 1)
      3. Refactor SSE/AVX float32/float64 abs/neg to use these macro-assembler
      helpers.
      4. Use these helpers in Liftoff too
      
      This has the benefit of not requiring to set up the masks in a temporary
      register, and loading the constants via an ExternalReference instead.
      It does require (in ins-sel) to have the input be in a Register, since
      the ExternalReference is an operand (and the instruction can only have 1
      operand input).
      
      Bug: v8:11589
      Change-Id: I68fafaf31b19ab05ee391aa3d54c45d547a85b34
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3123635Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76520}
      9996d8ae
  4. 21 Apr, 2021 1 commit
  5. 17 Apr, 2021 1 commit
    • Ng Zhi An's avatar
      Revert "[wasm-simd] Canonicalize shuffles when creating TurboFan graph" · ede5e814
      Ng Zhi An authored
      This reverts commit d16eefe0.
      
      It is not correct to check for node equality during the graph
      construction phase, because we can have optimizations that will combine
      same nodes. So it can happen that in wasm-compiler, the inputs to
      shuffle are not the same, so we canonicalize using that knowledge that
      it will not be the same, and allow indices > 15. But later we can have
      optimizations that combine the 2 inputs (e.g. splat of the same
      constants), and the instruction selector will see that the input nodes
      are the same.
      
      Bug: v8:11542,chromium:1199662
      Change-Id: I21c175f4707708038710147f64d687d1b14c6ecc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2829986
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74017}
      ede5e814
  6. 13 Apr, 2021 1 commit
  7. 22 Mar, 2021 1 commit
  8. 18 Mar, 2021 1 commit
  9. 17 Mar, 2021 1 commit
    • Ng Zhi An's avatar
      [wasm-simd] Canonicalize shuffles when creating TurboFan graph · d16eefe0
      Ng Zhi An authored
      We currently canonicalize shuffles in the architecture specific
      instruction selector. This has the drawback that if we want to pattern
      match on nodes that have a shuffle as input, they need to individually
      canonicalize the shuffle. There can also be a subtle bug if we
      canonicalize the same shuffle node twice (see bug for details).
      
      This moves the canonicalization to "construction time", in
      wasm-compiler, when building the graph. As such, any pattern matches in
      instruction-selector will only need to deal with canonicalized shuffles.
      
      We introduce a new kind of parameter for shuffle nodes,
      ShuffleParameter, to store the 16 bytes plus a bool indicating if this
      is a swizzle. A swizzle essentially: inputs to the shuffle are the same
      or all indices only touch 1 input. We calculate this when
      canonicalizing, so store this bit of information inside of the node's
      parameter.
      
      We update the tests in x64 to handle special cases where, even though
      the node's inputs are not swapped (due to canonicalization), they need
      to be swapped for the specific instruction selected (e.g. palignr). The
      test data also contains canonicalized shuffles, so we have to manually
      canonicalize them.
      
      Bug: v8:11542
      Change-Id: I4e78082267bd03d6caedf43d68d81ef3f5f364a8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2762420Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73495}
      d16eefe0
  10. 15 Mar, 2021 1 commit
  11. 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
  12. 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
  13. 01 Oct, 2020 1 commit
  14. 10 Aug, 2020 1 commit
  15. 12 Aug, 2019 1 commit
  16. 28 May, 2019 1 commit
  17. 27 May, 2019 1 commit
    • Clemens Hammacher's avatar
      [cleanup] Replace simple typedefs by using · a335f2ae
      Clemens Hammacher authored
      This replaces all typedefs that define types and not functions by the
      equivalent "using" declaration.
      
      This was done mostly automatically using this command:
      ag -l '\btypedef\b' src test | xargs -L1 \
           perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg'
      
      Patchset 2 then adds some manual changes for typedefs for pointer types,
      where the regular expression did not match.
      
      R=mstarzinger@chromium.org
      TBR=yangguo@chromium.org, jarin@chromium.org
      
      Bug: v8:9183
      Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61849}
      a335f2ae
  18. 23 May, 2019 1 commit
  19. 08 Mar, 2019 1 commit
  20. 18 Feb, 2019 1 commit
  21. 12 Nov, 2018 1 commit
  22. 16 Oct, 2018 1 commit
  23. 14 Jun, 2018 1 commit
    • jgruber's avatar
      Fix stack check pattern matching for CSA code · 9ff644ae
      jgruber authored
      The stack check instruction sequence is pattern-matched in
      instruction-selector-{ia32,x64}.cc and replaced with its own specialized
      opcode, for which we later generate an efficient stack check in a single
      instruction.
      
      But this pattern matching has never worked for CSA-generated code. The
      matcher expected LoadStackPointer in the right operand and the external
      reference load in the left operand. CSA generated exactly vice-versa.
      
      This CL does a few things; it
      1. reverts the recent change to load the
      limit from smi roots:
      
      Revert "[csa] Load the stack limit from smi roots"
      This reverts commit 507c29c9.
      
      2. tweaks the CSA instruction sequence to output what the matcher
      expects.
      3. refactors stack check matching into a new StackCheckMatcher class.
      4. typifies CSA::PerformStackCheck as a drive-by.
      
      Bug: v8:6666,v8:7844
      Change-Id: I9bb879ac10bfe7187750c5f9e7834dc4accf28b5
      Reviewed-on: https://chromium-review.googlesource.com/1099068Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53737}
      9ff644ae
  24. 29 Jan, 2018 1 commit
  25. 15 Jan, 2018 1 commit
  26. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored
      This patch normalizes the casing of hexadecimal digits in escape
      sequences of the form `\xNN` and integer literals of the form
      `0xNNNN`.
      
      Previously, the V8 code base used an inconsistent mixture of uppercase
      and lowercase.
      
      Google’s C++ style guide uses uppercase in its examples:
      https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
      
      Moreover, uppercase letters more clearly stand out from the lowercase
      `x` (or `u`) characters at the start, as well as lowercase letters
      elsewhere in strings.
      
      BUG=v8:7109
      TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
      NOPRESUBMIT=true
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
      Reviewed-on: https://chromium-review.googlesource.com/804294
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  27. 13 Mar, 2017 1 commit
  28. 23 Feb, 2017 1 commit
  29. 18 Oct, 2016 1 commit
    • zhengxing.li's avatar
      [turbofan][X64] Movzxbl/Movsxbl/Movzxwl/Movsxwl also zero extend to 64bit. · 3145befb
      zhengxing.li authored
        movzxbl/movsxbl/movzxwl/movsxwl operations implicitly zero-extend to 64-bit on x64, So It's not necessary to generate a "movl" instruction to zero-extend.
      
        For example, movzxbl/movl instruction sequence occurs frequently in v8 interpreter bytecode handler.
        such as:
        kind = BYTECODE_HANDLER
        name = LdaSmi
        compiler = turbofan
        Instructions (size = 76)
        0x184870a3ce40 0 430fbe442601 movsxbl rax,[r14+r12*1+0x1]
        0x184870a3ce46 6 48c1e020 REX.W shlq rax, 32
        0x184870a3ce4a 10 498d5c2402 REX.W leaq rbx,[r12+0x2]
        0x184870a3ce4f 15 420fb61433 movzxbl rdx,[rbx+r14*1]
        0x184870a3ce54 20 8bd2 movl rdx,rdx          <---------------------- here is a redundant "movl"
        0x184870a3ce56 22 4883fa1e REX.W cmpq rdx,0x1e
        0x184870a3ce5a 26 0f8518000000 jnz 56 (0x184870a3ce78)
      
        This CL also referenced to CL #36038 (https://codereview.chromium.org/1950013003 ) for adding test cases.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2427483002
      Cr-Commit-Position: refs/heads/master@{#40375}
      3145befb
  30. 18 Aug, 2016 1 commit
  31. 08 Aug, 2016 2 commits
  32. 05 Aug, 2016 2 commits
  33. 11 Dec, 2015 1 commit
  34. 10 Dec, 2015 1 commit
    • jarin's avatar
      [turbofan] Make MachineType a pair of enums. · bb2a830d
      jarin authored
      MachineType is now a class with two enum fields:
      - MachineRepresentation
      - MachineSemantic
      
      Both enums are usable on their own, and this change switches some places from using MachineType to use just MachineRepresentation. Most notably:
      - register allocator now uses just the representation.
      - Phi and Select nodes only refer to representations.
      
      Review URL: https://codereview.chromium.org/1513543003
      
      Cr-Commit-Position: refs/heads/master@{#32738}
      bb2a830d
  35. 29 Oct, 2015 1 commit
  36. 26 Oct, 2015 1 commit
    • rmcilroy's avatar
      [Interpreter] Add support for loading from / storing to outer context variables. · c0c214da
      rmcilroy authored
      Adds support for loading from and storing to outer context
      variables. Also adds support for declaring functions on contexts and
      locals. Finally, fixes a couple of issues with StaContextSlot where
      we weren't emitting the write barrier and therefore would crash in the
      GC.
      
      Also added code so that --print-bytecode will output the
      function name before the bytecodes, and replaces MachineType with StoreRepresentation in RawMachineAssembler::Store and updates tests.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1425633002
      
      Cr-Commit-Position: refs/heads/master@{#31584}
      c0c214da
  37. 11 Apr, 2015 1 commit
  38. 08 Apr, 2015 1 commit