1. 18 Oct, 2017 1 commit
  2. 13 Oct, 2017 1 commit
  3. 11 Oct, 2017 1 commit
  4. 10 Oct, 2017 2 commits
  5. 29 Sep, 2017 1 commit
  6. 28 Sep, 2017 1 commit
  7. 06 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [assembler] Make Register et al. real classes · 9e995e12
      Clemens Hammacher authored
      Up to now, each architecture defined all Register types as structs,
      with lots of redundancy. An often found comment noted that they cannot
      be classes due to initialization order problems. As these problems are
      gone with C++11 constexpr constants, I now tried making Registers
      classes again.
      All register types now inherit from RegisterBase, which provides a
      default set of methods and named constructors (like ::from_code,
      code(), bit(), is_valid(), ...).
      This design allows to guarantee an interesting property: Each register
      is either valid, or it's the no_reg register. There are no other
      invalid registers. This is guaranteed statically by the constexpr
      constructor, and dynamically by ::from_code.
      
      I decided to disallow the default constructor completely, so instead of
      "Register reg;" you now need "Register reg = no_reg;". This makes
      explicit how the Register is initialized.
      
      I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
      Overall, code got much more compact and more safe. In theory, it should
      also increase performance (since the is_valid() check is simpler), but
      this is probably not measurable.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
      Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47847}
      9e995e12
  8. 01 Sep, 2017 1 commit
  9. 17 Aug, 2017 1 commit
  10. 14 Jun, 2017 1 commit
  11. 13 Jun, 2017 1 commit
  12. 31 May, 2017 2 commits
    • neis's avatar
      [compiler] Delay allocation of code-embedded heap numbers. · 659e8f7b
      neis authored
      Instead of allocating and embedding certain heap numbers into the code
      during code assembly, emit dummies but record the allocation requests.
      Later then, in Assembler::GetCode, allocate the heap numbers and patch
      the code by replacing the dummies with the actual objects. The
      RelocInfos for the embedded objects are already recorded correctly when
      emitting the dummies.
      
      R=jarin@chromium.org
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2900683002
      Cr-Commit-Position: refs/heads/master@{#45635}
      659e8f7b
    • 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
  13. 15 Apr, 2017 1 commit
  14. 13 Apr, 2017 1 commit
  15. 12 Apr, 2017 1 commit
  16. 31 Mar, 2017 2 commits
  17. 15 Mar, 2017 1 commit
  18. 20 Jul, 2016 1 commit
  19. 29 Feb, 2016 1 commit
  20. 09 Dec, 2015 1 commit
  21. 07 Dec, 2015 1 commit
  22. 25 Nov, 2015 2 commits
    • jochen's avatar
      Make whether or not a Code object should be created by masm explicit · aa9cfc82
      jochen authored
      We always want to have an Isolate, so just use an extra ctor arg
      
      BUG=2487
      R=yangguo@chromium.org,mstarzinger@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/1476763002
      
      Cr-Commit-Position: refs/heads/master@{#32277}
      aa9cfc82
    • bmeurer's avatar
      [runtime] First step to sanitize regexp literal creation. · 09b44428
      bmeurer authored
      This is the initial step towards refactoring the regexp literation
      creation code to make it less obscure and more similar to the mechanism
      we use to create array and object literals.  There's now a new runtime
      entry %CreateRegExpLiteral with the same interface as the entries for
      array and object literals, except that we still pass the flags as
      string.
      
      Instead of embedding the hand written native to clone JSRegExp instances
      we now have a FastCloneRegExpStub, which behaves similar to the other
      FastCloneShallowArrayStub and FastCloneShallowObjectStub that we already
      had.
      
      R=mlippautz@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/1475823003
      
      Cr-Commit-Position: refs/heads/master@{#32255}
      09b44428
  23. 23 Nov, 2015 1 commit
  24. 20 Nov, 2015 1 commit
  25. 08 Oct, 2015 1 commit
  26. 11 Sep, 2015 1 commit
  27. 12 Aug, 2015 1 commit
    • jfb's avatar
      Security: disable nontemporals. · a904b569
      jfb authored
      The operations were available on ARM64 and x86-32 but were unused.
      
      It has been conjectured that nontemporals can be used for rowhammer-like bitflips more easily than regular load/store operations. It is therefore desirable to avoid generating these instructions in the future.
      
      R= titzer, jochen, jln, Mark Seaborn, ruiq
      
      Review URL: https://codereview.chromium.org/1276113002
      
      Cr-Commit-Position: refs/heads/master@{#30139}
      a904b569
  28. 21 Apr, 2015 1 commit
  29. 19 Mar, 2015 1 commit
  30. 30 Jan, 2015 3 commits
  31. 20 Dec, 2014 1 commit
  32. 19 Dec, 2014 1 commit
  33. 22 Oct, 2014 1 commit
  34. 16 Sep, 2014 1 commit