1. 17 Apr, 2020 1 commit
  2. 25 Feb, 2020 1 commit
  3. 16 Sep, 2019 1 commit
  4. 03 Sep, 2019 1 commit
    • Pierre Langlois's avatar
      [arm64] Fix backwards branch ranges. · ffffed90
      Pierre Langlois authored
      The `Instruction::IsValidImmPCOffset()` method was taking an `offset` argument
      in numbers of *instructions* while we were passing it numbers of *bytes*. See
      `Instruction::IsTargetInImmPCOffsetRange()` and
      `MacroAssembler::NeedExtraInstructionsOrRegisterBranch()`.
      
      As a result, we were 4 times too conservative when computing branch ranges going
      backwards, forcing us to generate the following sequence for TBZ more often than
      needed:
      
      ```
        TBNZ <skip>
        B <target>
      skip:
      ```
      
      This happened rarely for loops, but a lot when doing an early return from
      out-of-line calls to write barriers. Since out-of-line code is easily out of
      range of 8K, although the real range of TBZ is 32K.
      
      This fixes it by changing this method to take a byte offset instead of
      instructions, as this is more intuitive and in line with similar methods. For
      instance, `Instruction::ImmPcOffset()` returns an offset in bytes.
      
      The tests are adapted so that they would have caught such a bug:
      
      * TEST(far_branch_backward):
      
        This test used to only check the code worked if the branch was very far away,
        but it didn't test the range was correct. So this test was changed to check
        each branch type separately, and test in-range and out-of-range cases
        separately too.
      
      * TEST(far_branch_veneer_broken_link_chain):
      
        Because of the backwards range bug, this test wasn't actually testing what it
        should. The idea of the test is to make sure the MacroAssembler can still cope
        when the chain of links is broken after a veneer was emitted. But no veneers
        were ever emitted.
      
      Change-Id: Iddb5c683a71147455175f38fa7ae57da0a3e7337
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781058Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63518}
      ffffed90
  5. 28 May, 2019 1 commit
  6. 19 Dec, 2018 1 commit
  7. 24 Oct, 2018 1 commit
  8. 23 Oct, 2018 2 commits
  9. 07 Aug, 2018 1 commit
  10. 06 Jul, 2018 1 commit
  11. 20 Jun, 2018 1 commit
    • Ben L. Titzer's avatar
      [asm] Rework Assembler::IsolateData into Assembler::Options · 4252d53f
      Ben L. Titzer authored
      This CL attempts to simplify the Assembler's dependency on the
      isolate, in particular on a global "serializer_enabled" mode contained
      therein. The "serializer_enabled" condition enabled and disabled
      a number of things in both the assemblers and macro assemblers. To
      make these dependencies explicit, the Assembler::IsolateData is refactored
      to be a proper Assembler::Options struct that controls specific assembler
      behaviors, with default settings easily computable from the isolate.
      
      This also helps make the contract for compiling WASM code more explicit
      (since WASM code needs to have reloc info recorded for external references)
      we can explicitly enable this recording without trying to "trick" the
      assembler using "serializer_enabled".
      
      R=jgruber@chromium.org
      CC=mstarzinger@chromium.org, herhut@chromium.org
      
      Change-Id: I7a8ba49df7b75b292d73ec2aa6e507c27a3d99c8
      Reviewed-on: https://chromium-review.googlesource.com/1105982
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53890}
      4252d53f
  12. 18 Oct, 2017 1 commit
  13. 13 Oct, 2017 1 commit
  14. 13 Sep, 2017 1 commit
    • Mostyn Bramley-Moore's avatar
      [jumbo] fix arm64 builds · 46000a12
      Mostyn Bramley-Moore authored
      Previously instructions-arm64.h was alternatively defining or declaring
      some constants based on whether or not ARM64_DEFINE_FP_STATICS was defined,
      and it was assumed that exactly one file would include this header with
      the macro defined.
      
      In jumbo builds, the header guards in instructions-arm64.h meant that the
      resulting state of the header file would be whichever of the two cases
      that appeared first in the compilation unit.  This would cause multiple
      definitions in some cases and no definitions in some other cases (or if
      you were really lucky, it would work out ok).
      
      Let's move these constants to a separate source file temporarily, to be
      excluded from jumbo compilation units.  This code should eventually be
      replaced with a cleaner solution.
      
      Bug: chromium:746958
      Change-Id: I7edb1821ef408afd50c6b236d63d3c07f955b58f
      Reviewed-on: https://chromium-review.googlesource.com/663898
      Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48003}
      46000a12
  15. 31 May, 2017 1 commit
    • martyn.capewell's avatar
      Reland of Reland of "ARM64: Add NEON support" · fc3f29d3
      martyn.capewell authored
      This reverts commit c5aad5f2
      The CL was reverted due to missing Chromium dependencies.
      
      This commit removes the simulator trace-based tests, and the associated header file dependencies, previously pulled in by DEPS. The NEON support now has only hand-written tests, in test-assembler-arm64.cc. The remaining tests can be added in a later patch.
      
      BUG=chromium:718439
      
      Original issue's description:
      > Reland "ARM64: Add NEON support"
      >
      > This reverts commit cc047635.
      > The CL was reverted due to a missing DEPS mirror.
      >
      > Original issue's description:
      > > ARM64: Add NEON support
      > >
      > > Add assembler, disassembler and simulator support for NEON in the ARM64 backend.
      > >
      > > BUG=
      > >
      > > Review-Url: https://codereview.chromium.org/2622643005
      > > Cr-Commit-Position: refs/heads/master@{#44306}
      >
      > BUG=
      >
      > Review-Url: https://codereview.chromium.org/2812573003
      > Cr-Commit-Position: refs/heads/master@{#44652}
      
      Review-Url: https://codereview.chromium.org/2896303003
      Cr-Commit-Position: refs/heads/master@{#45633}
      fc3f29d3
  16. 22 May, 2017 1 commit
  17. 15 Apr, 2017 1 commit
  18. 13 Apr, 2017 1 commit
  19. 31 Mar, 2017 2 commits
  20. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
  21. 27 Nov, 2015 1 commit
  22. 17 Aug, 2015 1 commit
  23. 01 Jun, 2015 1 commit
  24. 20 May, 2015 1 commit
  25. 15 May, 2015 1 commit
  26. 19 Mar, 2015 1 commit
  27. 11 Sep, 2014 1 commit
  28. 04 Aug, 2014 1 commit
  29. 03 Jul, 2014 1 commit
  30. 20 Jun, 2014 1 commit
  31. 09 Jun, 2014 1 commit
  32. 03 Jun, 2014 1 commit
  33. 29 Apr, 2014 1 commit
  34. 07 Apr, 2014 1 commit
  35. 21 Mar, 2014 1 commit
  36. 18 Mar, 2014 1 commit
  37. 12 Mar, 2014 1 commit
  38. 18 Feb, 2014 1 commit
    • alexandre.rames@arm.com's avatar
      A64: Let the MacroAssembler resolve branches to distant targets. · 62116e2c
      alexandre.rames@arm.com authored
      Code generation would fail when assembling a branch to a label that is bound
      outside the immediate range of the instruction. A64 is sensitive to this, as the
      various branching instructions have different ranges, going down to +-32KB for
      TBZ/TBNZ.  The MacroAssembler is augmented to handle branches to targets that
      may exceed the immediate range of instructions.
      
      When branching backward to a label exceeding the instruction range, the
      MacroAssembler can simply tweak the generated code to use an unconditional
      branch with a longer range. For example instead of
          B(cond, &label);
      the MacroAssembler can generate:
          b(InvertCondition(cond), &done);
          b(&label);
          bind(&done);
      
      Since the target is not known when the branch is emitted, forward branches uses
      a different mechanism. The MacroAssembler keeps track of forward branches to
      unbound labels. When the code generation approaches the end of the range of a
      branch, a veneer is generated for the branch.
      
      BUG=v8:3148
      LOG=Y
      R=ulan@chromium.org
      
      Review URL: https://codereview.chromium.org/169893002
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      62116e2c