Skip to content

V
V8
Switch branch/tag
  1. 20 Sep, 2018 2 commits
  3. 19 Sep, 2018 2 commits
  5. 17 Sep, 2018 2 commits
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Initial support to compute NumberAdd/NumberSubtract in Word64. · 32aef42a
      Junliang Yan authored 
      Port 0c296cb2

Original Commit Message:

    This change introduces the necessary conversion operators to convert
    from Word64 to other representations (Tagged, Word32, Float64, etc.),
    and plugs in the Word64 representation for NumberAdd/NumberSubtract,
    such that TurboFan will go to Int64Add/Sub on 64-bit architectures
    when the inputs and the output of the operation is in safe integer
    range. This includes the necessary changes to the Deoptimizer to be
    able to rematerialize Int64 values as Smi/HeapNumber when going back
    to Ignition later.

    This change might affect performance, although measurements indicate
    that there should be no noticable performance impact.

    The goal is to have TurboFan support Word64 representation to a degree
    that changing the TypedArray length to an uint64_t (for 64-bit archs)
    becomes viable and doesn't have any negative performance implications.
    Independent of that we might get performance improvements in other areas
    such as for crypto code later.

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

Change-Id: I2119f156c4ddf942ea09ff8ed52e1c6cb32477f2
Reviewed-on: https://chromium-review.googlesource.com/1228634Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#55971}
      32aef42a
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Initial Word64 support in representation selection. · 89304433
      Junliang Yan authored 
      Port 6346cdb6

Original Commit Message:

    This adds support to TurboFan's representation selection for the Word64
    representation, and makes use of that to handle indices for memory access
    and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
    etc.). These instructions had previously used Word32 as representation
    for the indices / sizes, and then internally converted it to the correct
    representation (aka Word64 on 64-bit architectures) later on, but that
    was kind of brittle, and sometimes led to weird generated code.

    The change thus only adds support to convert integer values in the safe
    integer range from all kinds of representations to Word64 (on 64-bit
    architectures). We don't yet handle the opposite direction and none of
    the representation selection heuristics for the numeric operations were
    changed so far. This will be done in follow-up CLs.

    This CL itself is supposed to be neutral wrt. functionality, and only
    serves as a starting point, and a cleanup for the (weird) implicit
    Word64 index/size handling.

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

Change-Id: Ic7ea30639dea3c5f8a59e7100a15d5ed50073c20
Reviewed-on: https://chromium-review.googlesource.com/1228416Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#55970}
      89304433
  7. 13 Sep, 2018 2 commits
  9. 12 Sep, 2018 1 commit
  11. 05 Sep, 2018 1 commit
  13. 04 Sep, 2018 1 commit
  15. 14 Aug, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Further optimize DataView accesses. · 14170c67
      Junliang Yan authored 
      Port 5fecd146

Original Commit Message:

    This adds support for unaligned load/store access to the DataView
    backing store and uses byteswap operations to fix up the endianess
    when necessary. This changes the Word32ReverseBytes operator to be
    a required operator and adds the missing support on the Intel and
    ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
    is also mandatory now).

    This further improves the performance on the dataviewperf.js test
    mentioned in the tracking bug by up to 40%, and at the same time
    reduces the code complexity in the EffectControlLinearizer.

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

Change-Id: Ia9aad21713a2ad76ce3ef2b816fc20e9a27fe4c9
Reviewed-on: https://chromium-review.googlesource.com/1174936Reviewed-by: 's avatarJohn Barboza <jbarboza@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#55132}
      14170c67
  17. 07 Aug, 2018 1 commit
  19. 31 Jul, 2018 1 commit
  21. 27 Jul, 2018 1 commit
  23. 25 Jul, 2018 3 commits
  25. 12 Jul, 2018 1 commit
  27. 10 Jul, 2018 1 commit
  29. 09 Jul, 2018 1 commit
  31. 19 Jun, 2018 2 commits
  33. 15 Jun, 2018 1 commit
  35. 13 Jun, 2018 2 commits
  37. 06 Jun, 2018 2 commits
  39. 05 Jun, 2018 1 commit
  41. 04 Jun, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [wasm] Make stack check independent of the Isolate. · 94aac004
      Junliang Yan authored 
      Port c96ac82c

Original Commit Message:

    This makes stack checks in WasmCode independent of the underlying
    Isolate by loading the limit address from the WasmInstanceObject instead
    of embedding it into the instruction stream. It hence removes the last
    use of the Isolate field from WasmGraphBuilder.

    Additionally this introduces the notion of a "runtime stub" which
    represents stub code global to the NativeModule that can be directly
    called from each WasmCode in the same module. These stubs can act as
    trampolines via which Isolate-independent WasmCode can enter other V8
    builtins or runtime functions that remain Isolate-dependent. They will
    eventually replace the current "trampoline" in a NativeModule.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:7424
LOG=N

Change-Id: I5745a20133c930aecb80119e71ac1d8717e267bf
Reviewed-on: https://chromium-review.googlesource.com/1085276Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#53503}
      94aac004
  43. 14 May, 2018 2 commits
  45. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored 
      The idea is to mark all the branches and loads participating in array
bounds checks, and let them contribute-to/use the poisoning register.
In the code, the marks for array indexing operations now contain
"Critical" in their name. By default (--untrusted-code-mitigations),
we only instrument the "critical" operations with poisoning.

With that in place, we also remove the array masking approach based
on arithmetic.

Since we do not propagate the poison through function calls,
we introduce a node for poisoning an index that is passed through
function call - the typical example is the bounds-checked index
that is passed to the CharCodeAt builtin.

Most of the code in this CL is threads through the three levels of
protection (safe, critical, unsafe) for loads, branches and flags.

Bug: chromium:798964

Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
Reviewed-on: https://chromium-review.googlesource.com/995413
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  47. 26 Apr, 2018 3 commits
  49. 25 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored 
      I missed one required change which was hidden behind an #if. The fix is in
the diff between Patch 1 and Patch 3.

Original message:
In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

R=mstarzinger@chromium.org

Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73
  51. 24 Apr, 2018 2 commits
    • Andreas Haas's avatar
      Revert "[refactoring] Remove the isolate from signatures of ExternalReferences" · 7bfed2ad
      Andreas Haas authored 
      This reverts commit 44ea425a.

Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575

Original change's description:
> [refactoring] Remove the isolate from signatures of ExternalReferences
> 
> In this CL I remove the isolate from signatures of ExternalReference
> accessor functions where the isolate is not used. The uses of the
> isolate were already removed in previous CLs.
> 
> Changes:
> * I split the ExternalReference list in external-reference.h into
> those which need the isolate for initialization and those which do not.
> 
> * I removed the public constructors and replaced them by
>   ExternalReference::Create(). The reason is to separate external
>   creation more clearly from internal creation, because externally
>   created ExternalReferences sometimes need redirection, whereas
>   internally created ExternalReferences are just stored as they are.
>   In addition, by removing the isolate from the signature of the
>   public constructors, they suddenly exactly matched the interal
>   constructor.
> 
> * Replace all uses of the public constructors with
>   ExternalReference::Create().
> 
> * Remove the isolate from all call sites where necessary.
> 
> 
> This is a step towards making WebAssembly compilation independent of
> the isolate.
> 
> Bug: v8:7570
> R=​mstarzinger@chromium.org
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
> Reviewed-on: https://chromium-review.googlesource.com/1018982
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52768}

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

Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52769}
      7bfed2ad
    • Andreas Haas's avatar
      [refactoring] Remove the isolate from signatures of ExternalReferences · 44ea425a
      Andreas Haas authored 
      In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

Bug: v8:7570
R=mstarzinger@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
Reviewed-on: https://chromium-review.googlesource.com/1018982
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52768}
      44ea425a
  53. 16 Apr, 2018 1 commit