Skip to content

V
V8
Switch branch/tag
  1. 20 Oct, 2017 1 commit
  3. 18 Oct, 2017 2 commits
    • Pierre Langlois's avatar
      Simplify DoubleToI stub. · 9f4f3c28
      Pierre Langlois authored 
      The DoubleToI stub is no longer called outside of TurboFan, and always in the
same way:

  - The parameter is on top of the stack.
  - The stub is always called in a slow path.
  - It truncates.

Therefore, we can simplify it to only support this case and remove dead
code.

On top of this, since the stub is always considered to be on a slow path for all
backends, this patch takes the opportunity to remove the `skip_fastpath`
optimisation. This would generate a stub which does not handle all inputs,
assuming that the backend already handled some of the inputs in a fast
path. Removing this allows the stub to have the same behaviour on all targets.

On Arm, this patch reworks the stub a little. We could use ip instead of saving
and restoring a register on the stack. Also, comments would mention that we
assume the exponent to be greater than 31 when the it can be 30 or higher. As
done for Arm64, let's check this at runtime in debug mode.

On Arm64, we can also implement the stub without pushing and poping off the
stack. It needs 2 general purpose and a double scratch registers which we have
reserved already (ip0, ip1 and d30). This removes the need to check that the
stack pointer is always 16-bytes aligned.

Finally, this also fixes a potential bug on Arm64, in the
`GetAllocatableRegisterThatIsNotOneOf` method which is now removed. We were
picking an allocatable double register when we meant to pick a general one.

Bug: v8:6644
Change-Id: I88d4597f377c9fc05432d5922a0d7129b6d19b47
Reviewed-on: https://chromium-review.googlesource.com/720963Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48671}
      9f4f3c28
    • Clemens Hammacher's avatar
      [cleanup] Fix remaining (D)CHECK macro usages · 5f651082
      Clemens Hammacher authored 
      This CL fixes all occurences that don't require special OWNER reviews,
or can be reviewed by Michi.

After this one, we should be able to reenable the readability/check
cpplint check.

R=mstarzinger@chromium.org

Bug: v8:6837, v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62
Reviewed-on: https://chromium-review.googlesource.com/721120
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48670}
      5f651082
  5. 13 Oct, 2017 3 commits
  7. 09 Oct, 2017 2 commits
  9. 14 Sep, 2017 1 commit
  11. 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
  13. 08 Sep, 2017 1 commit
  15. 01 Sep, 2017 1 commit
  17. 24 Aug, 2017 1 commit
  19. 23 Aug, 2017 1 commit
  21. 14 Aug, 2017 1 commit
  23. 07 Aug, 2017 3 commits
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · ee350c31
      Benedikt Meurer authored 
      Drop the deprecated CallConstructStub and remove the use of CallICStub
from fullcodegen, since that feedback is unused completely every since
Crankshaft got removed, thus we can safely unlink all the CallIC stuff
from fullcodegen nowadays, and completely nuke the CallICStub and the
CallICTrampolineStub now (we can also transitively nuke the unused
CreateAllocationSiteStub and CreateWeakCellStub).

Instead the CallIC logic is integrated into Ignition now, and part of
the bytecode handlers for [[Call]] and [[Construct]]. There's still some
follow-up cleanup with the way the Array constructor feedback is
integrated, but that's way easier now.

Bug: v8:5517, v8:6399, v8:6409, v8:6679
Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619
Reviewed-on: https://chromium-review.googlesource.com/603609
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47196}
      ee350c31
    • Michael Achenbach's avatar
      Revert "[ic] Properly integrate the CallIC into Ignition." · 018128a4
      Michael Achenbach authored 
      This reverts commit 6c541561.

Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap/builds/17240

Original change's description:
> [ic] Properly integrate the CallIC into Ignition.
> 
> Drop the deprecated CallConstructStub and remove the use of CallICStub
> from fullcodegen, since that feedback is unused completely every since
> Crankshaft got removed, thus we can safely unlink all the CallIC stuff
> from fullcodegen nowadays, and completely nuke the CallICStub and the
> CallICTrampolineStub now (we can also transitively nuke the unused
> CreateAllocationSiteStub and CreateWeakCellStub).
> 
> Instead the CallIC logic is integrated into Ignition now, and part of
> the bytecode handlers for [[Call]] and [[Construct]]. There's still some
> follow-up cleanup with the way the Array constructor feedback is
> integrated, but that's way easier now.
> 
> Bug: v8:5517, v8:6399, v8:6409, v8:6679
> Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
> Reviewed-on: https://chromium-review.googlesource.com/602134
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47192}

TBR=rmcilroy@chromium.org,yangguo@chromium.org,bmeurer@chromium.org

Change-Id: I416ce6646f62ceb4127b3acee43912ee0d701c23
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:5517, v8:6399, v8:6409, v8:6679
Reviewed-on: https://chromium-review.googlesource.com/603647Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47193}
      018128a4
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · 6c541561
      Benedikt Meurer authored 
      Drop the deprecated CallConstructStub and remove the use of CallICStub
from fullcodegen, since that feedback is unused completely every since
Crankshaft got removed, thus we can safely unlink all the CallIC stuff
from fullcodegen nowadays, and completely nuke the CallICStub and the
CallICTrampolineStub now (we can also transitively nuke the unused
CreateAllocationSiteStub and CreateWeakCellStub).

Instead the CallIC logic is integrated into Ignition now, and part of
the bytecode handlers for [[Call]] and [[Construct]]. There's still some
follow-up cleanup with the way the Array constructor feedback is
integrated, but that's way easier now.

Bug: v8:5517, v8:6399, v8:6409, v8:6679
Change-Id: Ia0efc6145ee64633757a6c3fd1879d4906ea2835
Reviewed-on: https://chromium-review.googlesource.com/602134
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47192}
      6c541561
  25. 04 Aug, 2017 1 commit
  27. 03 Aug, 2017 2 commits
  29. 02 Aug, 2017 1 commit
    • Yang Guo's avatar
      Support circular references between generated builtins. · 266be35b
      Yang Guo authored 
      Until now, when generating a builtin, it can only embed builtins
(as call targets) that have already been generated. This is either
achieved by reordering the builtins list, or by loading the call
target at runtime from the builtins list (see
MacroAssembler::TailCallBuiltin).

This patch works around this issue by filling the builtins list
with dummy code objects, which are later replaced with the completed
actual builtins. In release mode, this adds around 3ms to 140ms we
previously needed to populate the builtins list. 

Change-Id: I7d451b3c09a1db4b9e755548102a80c7f0dfada2
Reviewed-on: https://chromium-review.googlesource.com/586531
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47062}
      266be35b
  31. 01 Aug, 2017 2 commits
    • Jaideep Bajwa's avatar
      PPC/s390: MIPS[64] Fix SizeOfInitialHeap test failing · 788d8289
      Jaideep Bajwa authored 
      Port 316254a7

Original Commit Message:

    Commit 0d833cb9 deleted function call
    that created CEntryStub code in snapshot. So when CEntryStub::GetCode is
    called while initializing V8, the code for it, is not found in shapshot.
    Hence this code has to be generated in new allocation on heap, that is
    why initial heap is above the limit.
    This patch assures that CEntryStub code is in the snapshot.

R=predrag.rudic@imgtec.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I976dacf885e0d4ce8c5446a2c560a00cc0792150
Reviewed-on: https://chromium-review.googlesource.com/596071Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47054}
      788d8289
    • jgruber's avatar
      Reland "[builtins] Remove Builtins::Name() accessors" · fcaa2c2e
      jgruber authored 
      This is a reland of 2f79e035
Original change's description:
> [builtins] Remove Builtins::Name() accessors
> 
> Instead of auto-generating the Name() convenience accessor, use a macro to
> avoid wasting code space.
> 
>   BUILTIN_CODE(isolate, Name)
> 
> expands to
> 
>   isolate->builtins()->builtin_handle(Builtins::kName);
> 
> This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
> 
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
> Reviewed-on: https://chromium-review.googlesource.com/593607
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47010}

TBR=bmeurer@chromium.org,ahaas@chromium.org

Bug: v8:6624
Change-Id: I4733731e56dc8873ee06c2b36cac1918c0a658b2
Reviewed-on: https://chromium-review.googlesource.com/594087
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47037}
      fcaa2c2e
  33. 31 Jul, 2017 2 commits
    • Jakob Gruber's avatar
      Revert "[builtins] Remove Builtins::Name() accessors" · 17a26c0b
      Jakob Gruber authored 
      This reverts commit 2f79e035.

Reason for revert: Conflicts with successor CL.

Original change's description:
> [builtins] Remove Builtins::Name() accessors
> 
> Instead of auto-generating the Name() convenience accessor, use a macro to
> avoid wasting code space.
> 
>   BUILTIN_CODE(isolate, Name)
> 
> expands to
> 
>   isolate->builtins()->builtin_handle(Builtins::kName);
> 
> This reduces the size of libv8.so by 134,752 bytes on a x64 release build.
> 
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
> Reviewed-on: https://chromium-review.googlesource.com/593607
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47010}

TBR=yangguo@chromium.org,ahaas@chromium.org,jgruber@chromium.org,bmeurer@chromium.org

Change-Id: Ia9ef5c755b26c3f4e143d87a7c51033614ea435e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/594048Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47012}
      17a26c0b
    • jgruber's avatar
      [builtins] Remove Builtins::Name() accessors · 2f79e035
      jgruber authored 
      Instead of auto-generating the Name() convenience accessor, use a macro to
avoid wasting code space.

  BUILTIN_CODE(isolate, Name)

expands to

  isolate->builtins()->builtin_handle(Builtins::kName);

This reduces the size of libv8.so by 134,752 bytes on a x64 release build.

Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idff7ee5c45e344e73412c0f47e92553c7c7ff75f
Reviewed-on: https://chromium-review.googlesource.com/593607Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47010}
      2f79e035
  35. 28 Jul, 2017 1 commit
  37. 26 Jul, 2017 2 commits
    • Jaideep Bajwa's avatar
      PPC/s390: [turbofan] Widen the fast-path for JSCreateArray. · 00a8ab2e
      Jaideep Bajwa authored 
      Port 1edb46cc

Original Commit Message:

    This improves the general Array constructor call performance (w/o
    usable AllocationSite feedback) in TurboFan by ~2x, i.e. for example
    invoking the Array constructor like this

      var a = Array.call(undefined, n);

    instead of

      var a = Array(n);

    such that the CallIC doesn't know that it's eventually calling the
    Array constructor.

    It also thus changes the single argument Array constructor to always
    return holey arrays. Previously the single argument case for the Array
    constructor was somehow trying to dynamically detect 0 and in that case
    returned a packed array instead of a holey one. That adds quite a lot
    of churn, and doesn't seem to be very useful, especially since this
    might lead to unnecessary feedback pollution later.

R=bmeurer@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I6a50ae016556ed38a7d7ca5546b575ca25e91b4a
Reviewed-on: https://chromium-review.googlesource.com/586641Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#46909}
      00a8ab2e
    • Jaideep Bajwa's avatar
      PPC/s390: Move TF parts of MacroAssembler into new TurboAssembler. · 2b23e892
      Jaideep Bajwa authored 
      Port dfdcaf43
Port 2e1f5567

Original Commit Message:

    This CL introduces TurboAssembler, a super-class of Assembler and sub-class
    of MacroAssembler. TurboAssembler contains all the functionality that is used
    by Turbofan and previously was part of MacroAssembler. TurboAssembler has
    access to the isolate but, in contrast to MacroAssembler, does not expect to
    be running on the main thread.

R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:6048
LOG=N

Change-Id: I3f51771afefe46410db7cda2625472d78c87f8c6
Reviewed-on: https://chromium-review.googlesource.com/583584Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#46900}
      2b23e892
  39. 24 Jul, 2017 1 commit
  41. 13 Jul, 2017 2 commits
  43. 10 Jul, 2017 2 commits
  45. 05 Jul, 2017 2 commits
  47. 30 Jun, 2017 1 commit
    • Mathias Bynens's avatar
      [elements] Rename FAST elements kinds · 26c00f4a
      Mathias Bynens authored 
      The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.

This patch renames the FAST elements kinds as follows:

- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS

The following exceptions are left intact, for lack of a better name:

- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS

This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.

R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
      26c00f4a
  49. 29 Jun, 2017 1 commit
  51. 26 Jun, 2017 2 commits