1. 04 Jan, 2018 1 commit
  2. 21 Dec, 2017 1 commit
  3. 12 Dec, 2017 2 commits
  4. 08 Dec, 2017 2 commits
  5. 30 Nov, 2017 2 commits
  6. 22 Nov, 2017 1 commit
  7. 13 Nov, 2017 1 commit
  8. 25 Oct, 2017 3 commits
  9. 24 Oct, 2017 1 commit
    • Clemens Hammacher's avatar
      Allow constexpr RegList construction from Registers · fd306a06
      Clemens Hammacher authored
      Before, the standard way to create a RegList was either:
      RegList list = (1 << 0) | (1 << 1) | ...
      or
      RegList list = rax.bit() | rdx.bit() | ...
      
      The first way allows to make the RegList constexpr, but needs comments
      to document which registers you are referring to, and it has no checks
      that all bits you set on the RegList actually belong to valid registers.
      The second one uses the symbolic names, hence is much more readable and
      makes it harder to construct invalid RegLists. It's not constexpr
      though, since the {bit()} method on the register types is not constexpr.
      
      This CL adds a constexpr accessor to get the code and bit of a
      constexpr Register, and adds a helper method to create a constexpr
      RegList like this:
      constexpr RegList list = Register::ListOf<rax, rdx, rdi>();
      
      This new method is used in a number of places to test its
      applicability. Other uses of the old pattern remain and can be cleaned
      up later.
      
      R=tebbi@chromium.org
      
      Change-Id: Ie7b1d6342dc5f316dcfedd0363b3540ad5e7f413
      Reviewed-on: https://chromium-review.googlesource.com/728026
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48887}
      fd306a06
  10. 20 Oct, 2017 1 commit
  11. 18 Oct, 2017 5 commits
  12. 13 Oct, 2017 2 commits
  13. 12 Oct, 2017 1 commit
  14. 04 Oct, 2017 1 commit
  15. 02 Oct, 2017 1 commit
  16. 15 Sep, 2017 1 commit
  17. 14 Sep, 2017 1 commit
  18. 11 Sep, 2017 2 commits
  19. 09 Sep, 2017 1 commit
    • Anisha Rohra's avatar
      s390/PPC: Make Register et al. real classes · 0b491c89
      Anisha Rohra authored
      Port 9e995e12
      Port 408f252b
      
        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=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2e87efc8790290c64fd6c0a2d093326710b30ed3
      Reviewed-on: https://chromium-review.googlesource.com/658065Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47933}
      0b491c89
  20. 07 Sep, 2017 2 commits
  21. 06 Sep, 2017 2 commits
    • Anisha Rohra's avatar
      s390/PPC: Remove InterpreterExitTrampoline. · 40c98daa
      Anisha Rohra authored
      Port 30f08f39
      
        Always return to the InterpreterEntryTrampoline rather than calling the
        InterpreterExitTrampoline from the Return bytecode handler. This fixes a
        regression which occured if we upset the call/return stack by skipping the
        return to the InterpreterEntryTrampoline from the return bytecode handler.
      
      R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Id2bae444e72cd7ddfb74f4861fc2c4f7b5e9bda5
      Reviewed-on: https://chromium-review.googlesource.com/653618Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47858}
      40c98daa
    • Anisha Rohra's avatar
      s390/PPC: Remove weak-list of optimized JS functions. · 1902b5a9
      Anisha Rohra authored
      Port f0acede9
      
      This CL removes the weak-list of JS functions from the context
      and all the code that iterares over it. This list was being used
      mainly during deoptimization (for code unlinking) and during
      garbage collection. Removing it will improve performance of
      programs that create many closures and trigger many scavenge GC
      cycles.
      
      No extra work is required during garbage collection. However,
      given that we no longer unlink code from JS functions during
      deoptimization, we leave it as it is, and on its next activation
      we check whether the mark_for_deoptimization bit of that code is
      set, and if it is, than we unlink it and jump to lazy compiled
      code. This check happens in the prologue of every code object.
      
      We needed to change/remove the cctests that used to check
      something on this list.
      
      R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I8007a837d43b6a339789cfd727e81ad7f4ac3ae1
      Reviewed-on: https://chromium-review.googlesource.com/651891Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47840}
      1902b5a9
  22. 29 Aug, 2017 1 commit
    • Jaideep Bajwa's avatar
      PPC/s390: [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · e5b93bd5
      Jaideep Bajwa authored
      Port 51a15140
      
      Original Commit Message:
      
          This change adapts the Call bytecode handlers such that they don't require
          a stack frame. It does this by modifying the call bytecode handler to
          tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
          callee function will return to the InterpreterEntryTrampoline when it returns
          (since this is the return address on the interpreter frame), which is
          adapted to dispatch to the next bytecode handler. The return bytecode
          handler is modified to tail-call a new InterpreterExitTramoline instead
          of returning to the InterpreterEntryTrampoline.
      
          Overall this significanlty reduces the amount of stack space required for
          interpreter frames, increasing the maximum depth of recursive calls from
          around 6000 to around 12,500 on x64.
      
      R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=chromium:753705
      LOG=N
      
      Change-Id: Ieac490d82098c13741080061eda762d54baf8c04
      Reviewed-on: https://chromium-review.googlesource.com/639315Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47694}
      e5b93bd5
  23. 25 Aug, 2017 1 commit
  24. 24 Aug, 2017 1 commit
  25. 23 Aug, 2017 2 commits
    • Jaideep Bajwa's avatar
      PPC/S390: Fix to use 32 bit load · 4274e71c
      Jaideep Bajwa authored
      The testcase was failing on BE, fix to use 32bit load
      before calling testbit.
      
      R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      Log=N
      
      Bug: 
      Change-Id: I075666b47dd90b6341ba7b4031cd4be96e8c1bf9
      Reviewed-on: https://chromium-review.googlesource.com/628659Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#47556}
      4274e71c
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove code aging support." · 8bf15bf1
      Ross McIlroy authored
      > This reverts commit 42d3d36b.
      > 
      > Original change's description:
      > > [Compiler] Remove code aging support.
      > > 
      > > Code aging is no longer supported by any remaining compilers now
      > > that full codegen has been removed. This CL removes all vestiges of
      > > code aging.
      > > 
      > > BUG=v8:6409
      > > 
      > > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
      > > Reviewed-on: https://chromium-review.googlesource.com/619153
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#47501}
      > 
      > TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      > 
      > Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6409
      > Reviewed-on: https://chromium-review.googlesource.com/625998
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47506}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      
      Change-Id: I68785c6be7686e874b3848103e3a34483eaeb519
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6409
      Reviewed-on: https://chromium-review.googlesource.com/625919Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47535}
      8bf15bf1
  26. 22 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      Revert "[Compiler] Remove code aging support." · 42d3d36b
      Ross McIlroy authored
      This reverts commit a205117c.
      
      Reason for revert: breaks Arm64
      
      Original change's description:
      > [Compiler] Remove code aging support.
      > 
      > Code aging is no longer supported by any remaining compilers now
      > that full codegen has been removed. This CL removes all vestiges of
      > code aging.
      > 
      > BUG=v8:6409
      > 
      > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
      > Reviewed-on: https://chromium-review.googlesource.com/619153
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47501}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      
      Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6409
      Reviewed-on: https://chromium-review.googlesource.com/625998Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47506}
      42d3d36b