Skip to content

V
V8
Switch branch/tag
  1. 04 Jan, 2018 1 commit
  3. 21 Dec, 2017 1 commit
  5. 12 Dec, 2017 2 commits
  7. 08 Dec, 2017 2 commits
  9. 30 Nov, 2017 2 commits
  11. 22 Nov, 2017 1 commit
  13. 13 Nov, 2017 1 commit
  15. 25 Oct, 2017 3 commits
  17. 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
  19. 20 Oct, 2017 1 commit
  21. 18 Oct, 2017 5 commits
  23. 13 Oct, 2017 2 commits
  25. 12 Oct, 2017 1 commit
  27. 04 Oct, 2017 1 commit
  29. 02 Oct, 2017 1 commit
  31. 15 Sep, 2017 1 commit
  33. 14 Sep, 2017 1 commit
  35. 11 Sep, 2017 2 commits
  37. 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
  39. 07 Sep, 2017 2 commits
  41. 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
  43. 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
  45. 25 Aug, 2017 1 commit
  47. 24 Aug, 2017 1 commit
  49. 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
  51. 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