Skip to content

V
V8
Switch branch/tag
  1. 26 Mar, 2019 1 commit
  3. 25 Mar, 2019 1 commit
  5. 19 Mar, 2019 1 commit
  7. 15 Mar, 2019 1 commit
  9. 12 Mar, 2019 1 commit
  11. 08 Mar, 2019 1 commit
  13. 07 Mar, 2019 1 commit
  15. 25 Feb, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [objects] Free one bit in the SharedFunctionInfo::flags. · 942dc585
      Junliang Yan authored 
      Port 591408cb

Original Commit Message:

    We'll need one bit in the SharedFunctionInfo::flags to record whether
    it's safe to skip arguments adaptor frames (for v8:8895), so this
    just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
    redundant, since the same information is already available in the
    SharedFunctionInfo::FunctionKindBits, and most places in the code
    use that already, with the exception of the JSConstructStubGeneric
    builtin.

    This changes the JSConstructStubGeneric builtin to just check the
    function kind instead of testing the explicit bit, which also makes
    this more consistent. It seems like there's not much overhead to
    that, doing an additional bitmasking plus two comparisons instead
    of one. This shouldn't really matter since invocation and execution
    of the constructors is going to dominate and optimized code inlines
    all of this anyways. If this turns out to affect performance, we
    can still look into encoding the FunctionKindBits more cleverly.

    the shift when accessing the function kind. This seems logic, since
    for the actual boolean bit fields it doesn't matter where they are
    in the flags, whereas for the function kind this saves one shift.

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

Change-Id: I4e3ba5a066285bf50e869c32228d79d26d57258f
Reviewed-on: https://chromium-review.googlesource.com/c/1486411Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59837}
      942dc585
  17. 21 Feb, 2019 1 commit
    • Farazmand's avatar
      PPC/s390: [cleanup] Remove obsolete representations. · f8696d4e
      Farazmand authored 
      Port adb7e37b

Original Commit Message:

    In the Crankshaft days we (mis)used the Representation to also express
    the various internal representations that the compiler understands. But
    with TurboFan we now have proper MachineRepresentation and MachineType,
    which do that independently. So there's no need to have this in the
    Representation class anymore, and instead the Representation class only
    needs to deal with the field representations.

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

Change-Id: Ie3c8062786d5fd42872e22be01cea45d719ea0a4
Reviewed-on: https://chromium-review.googlesource.com/c/1479972Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59767}
      f8696d4e
  19. 15 Feb, 2019 2 commits
  21. 13 Feb, 2019 3 commits
  23. 11 Feb, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: DISALLOW_IMPLICIT_CONSTRUCTORS for MacroAssembler · 47270ebf
      Junliang Yan authored 
      Port 9e060e47

Original Commit Message:

    When BUILDING_V8_SHARED in release builds __declspec(dllexport)
    causes generation of implicit constructors in the forwarding class
    while its deleted in TurboAssemblerBase, which leads to compilation
    errors like:

    In file included from gen/v8/v8_base_jumbo_6.cc:41:
    In file included from .\../../v8/src/interface-descriptors.cc:7:
    In file included from ../../v8\src/macro-assembler.h:40:
    ../../v8\src/x64/macro-assembler-x64.h(92,9):  error: call to deleted constructor of 'v8::internal::TurboAssemblerBase'
          : TurboAssemblerBase(std::forward<Args>(args)...) {}
            ^                  ~~~~~~~~~~~~~~~~~~~~~~~~
    ../../v8\src/x64/macro-assembler-x64.h(536,25):  note: in instantiation of function template specialization 'v8::internal::TurboAssembler::TurboAssembler<v8::internal::TurboAssembler>' requested here
    class V8_EXPORT_PRIVATE MacroAssembler : public TurboAssembler {
                            ^
    ../../v8\src/turbo-assembler.h(127,34):  note: 'TurboAssemblerBase' has been explicitly marked deleted here
      DISALLOW_IMPLICIT_CONSTRUCTORS(TurboAssemblerBase);
                                     ^
    1 error generated.

    The original changes were made in https://chromium-review.googlesource.com/c/v8/v8/+/1414913

R=hop2deep@gmail.com, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I2a6e555b028583b89402b257e40757f34f3301c1
Reviewed-on: https://chromium-review.googlesource.com/c/1463179Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59499}
      47270ebf
  25. 07 Feb, 2019 1 commit
  27. 06 Feb, 2019 1 commit
  29. 01 Feb, 2019 1 commit
  31. 30 Jan, 2019 2 commits
  33. 28 Jan, 2019 1 commit
  35. 17 Jan, 2019 3 commits
  37. 16 Jan, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [assembler] Allow to pass custom buffer implementations · 943b5d02
      Junliang Yan authored 
      Port 1a3aab51

Original Commit Message:

    When generating an Assembler, you currently have two choices: Either
    let the Assembler allocate a growable internal buffer, which is owned
    by the Assembler. Or provide an externally allocated buffer, which
    cannot grow.
    This CL changes this interface to allow providing any implementation of
    a buffer. The provided buffer can be a view to an externally owned
    buffer, which still can grow.
    This will be used to split WebAssembly compilation and code submission.
    The buffer needs to be able to grow, but cannot be owned by the
    Assembler because it has to survive until the code is submitted.

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

Change-Id: Id9383db813b13ea1d9eab485724aeb55b08cdfee
Reviewed-on: https://chromium-review.googlesource.com/c/1416310Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58865}
      943b5d02
  39. 15 Jan, 2019 1 commit
  41. 14 Jan, 2019 1 commit
  43. 11 Jan, 2019 2 commits
    • Junliang Yan's avatar
      PPC/s390: [Deopt] Remove jump table in prologue of deopt entries. · 2afe66c5
      Junliang Yan authored 
      Port 4ab96a9a

Original Commit Message:

    Remove the use of a jump table in the prologue of the deopt entries
    and instead pass the bailout id explicitly in a register when calling
    the deopt entry routine from optimized code. This unifies the logic
    with the way the Arm64 code works. It saves the following amount of
    memory in code stubs:

     - arm:  384KB
     - ia32: 480KB
     - x64:  240KB

    This could be offset by a slight increase in the size of optimized code
    for loading the immediate, however this impact should be minimal and
    will scale with the maximum number of bailout ids (e.g., the size of
    code will increase by one instruction per bailout id on Arm, therefore
    ~98,000 bailouts will be needed before the overhead is greater than
    the current fixed table size).

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

Change-Id: Id5762334b21e6a91e5ce44b7db1e38ace9147372
Reviewed-on: https://chromium-review.googlesource.com/c/1406026
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58752}
      2afe66c5
    • Jakob Gruber's avatar
      Remove fast_sqrt generated code · f3a23acc
      Jakob Gruber authored 
      As far as I can tell these were unused; their only callers were arm
and ppc simulators, but codegen explicitly returned nullptr if in a
simulator build, falling back to std::sqrt.

There's more potential cleanup to be done here for other functions
defined in codegen-*.cc files.

Tbr: clemensh@chromium.org
Bug: v8:7777, v8:8675
Change-Id: I4b9d6062c6724a810ab094d09e3cd04a0b733d9b
Reviewed-on: https://chromium-review.googlesource.com/c/1405851Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58740}
      f3a23acc
  45. 08 Jan, 2019 1 commit
  47. 07 Jan, 2019 2 commits
  49. 03 Jan, 2019 4 commits
    • Junliang Yan's avatar
      PPC/s390: [ubsan] Port HeapObject to the new design · bc344e38
      Junliang Yan authored 
      Port 9302db48

Original Commit Message:

    Merging the temporary HeapObjectPtr back into HeapObject.

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

Change-Id: I4f92282b7b4c66bb73da30e076a8378e0cf24836
Reviewed-on: https://chromium-review.googlesource.com/c/1394813Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58534}
      bc344e38
    • Junliang Yan's avatar
      PPC/s390: [ubsan] Let Runtime functions return a plain Address · 657d979f
      Junliang Yan authored 
      Port f1cb51ad

Original Commit Message:

    instead of Object* (which is deprecated) or ObjectPtr (which is
    unsuitable for cases where we need to control the ABI exactly).
    Callers in generated code expect a plain tagged value, so return
    precisely that. Same for C++ Builtins.

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

Change-Id: I8055c9a9c99dbe8716f810c6b6cc1967bed9c3de
Reviewed-on: https://chromium-review.googlesource.com/c/1393920Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58531}
      657d979f
    • Junliang Yan's avatar
      PPC/s390: [nojit] Change builtin pointers to use Smis underneath · 9f68ab24
      Junliang Yan authored 
      Port fa3cbf60

Original Commit Message:

    This changes Torque's builtin pointers to use a Smi representation
    underneath instead of storing the Code target object. Callsites look
    up the target entry point through IsolateData::builtin_entry_table.

    The notable effect of this CL is that builtin pointer calls no longer
    call any on-heap Code.

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

Change-Id: I49bb08de916fd93e576936a56b0e1a0e21072289
Reviewed-on: https://chromium-review.googlesource.com/c/1394301Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58530}
      9f68ab24
    • Junliang Yan's avatar
      PPC/s390: [nojit] Add a kCallBuiltinPointer call kind · 4812f2af
      Junliang Yan authored 
      Port f323a5f4

Original Commit Message:

    Currently, Torque's builtin pointers store a Code target underneath and
    callsites generate a kArchCallCodeObject opcode. When embedded builtins
    are enabled, the call thus first calls the on-heap trampoline, which
    finally jumps to the target off-heap builtin code.

    This will no longer be possible in jitless mode, since on-heap code must
    not be executable.

    As a step towards changing the way builtin pointers are called
    (function pointers will hold the builtin index as a Smi, and callsites
    look up the off-heap target address and jump there), this CL adds a
    dedicated opcode for builtin pointer calls to the compiler pipeline.

    The calling mechanism itself is unchanged, changes there will happen
    in a follow-up.

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

Change-Id: I2d2229227e1c62e7c2515d4f5cb3d4dae49b3dd4
Reviewed-on: https://chromium-review.googlesource.com/c/1393913Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58525}
      4812f2af
  51. 02 Jan, 2019 3 commits
  53. 26 Dec, 2018 1 commit