1. 23 Apr, 2019 1 commit
  2. 01 Apr, 2019 1 commit
  3. 26 Mar, 2019 1 commit
  4. 25 Mar, 2019 1 commit
  5. 08 Mar, 2019 1 commit
  6. 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
  7. 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
  8. 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
  9. 28 Jan, 2019 1 commit
  10. 17 Jan, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: Use forwarding constructors for MacroAssembler · 30617b77
      Junliang Yan authored
      Port edab9a20
      
      Original Commit Message:
      
          and TurboAssembler. Instead of listing all the different combinations
          of arguments (which is one more now, temporarily), just forward all
          arguments down via MacroAssembler and TurboAssembler to
          TurboAssemblerBase.
          Interestingly, this requires more specific types sometimes (int instead
          of size_t), since further down the forwarding chain, the compiler does
          not recognize any more that the value is a constant, and emits a
          warning about a possibly truncating implicit conversion.
      
      R=clemensh@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I6dddc58b81d020570087393158f4ad0f37efa9ce
      Reviewed-on: https://chromium-review.googlesource.com/c/1417379Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58889}
      30617b77
  11. 11 Jan, 2019 1 commit
    • 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
  12. 07 Jan, 2019 1 commit
  13. 03 Jan, 2019 1 commit
    • 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
  14. 02 Jan, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: Reland "[nojit] Remove code stubs" · 4af9ec6a
      Junliang Yan authored
      Port 24e76616
      
      Original Commit Message:
      
          This is a reland of f849396c
      
          Original change's description:
          > [nojit] Remove code stubs
          >
          > All stubs have been migrated to builtins. This CL removes most related
          > code.
          >
          > Bug: v8:7777, v8:5784
          > Change-Id: I4470cfef34788e6c8e0fd5fd09e40e250d088dad
          > Reviewed-on: https://chromium-review.googlesource.com/c/1365284
          > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
          > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
          > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
          > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
          > Reviewed-by: Yang Guo <yangguo@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#58093}
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ie05463245c24975804a8bb7ffdf902c70e042127
      Reviewed-on: https://chromium-review.googlesource.com/c/1393302Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58504}
      4af9ec6a
  15. 19 Dec, 2018 1 commit
  16. 07 Dec, 2018 1 commit
  17. 05 Dec, 2018 1 commit
  18. 29 Nov, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
      
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Patchset 1 is the original CL.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
      Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
  19. 26 Nov, 2018 1 commit
  20. 19 Nov, 2018 3 commits
  21. 16 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [iwyu] Ensure that macro assembler includes happen correctly · 1952f928
      Clemens Hammacher authored
      The platform specific macro assembler headers can not be included
      directly. They require symbols declared in macro-assembler.h.
      We also cannot include macro-assembler.h from the platform specific
      headers, because that would form a cycle, and the include in
      macro-assembler.h would be skipped, which then also fails.
      
      This CL documents and enforces this unfortunate situation.
      This helps with further iwyu cleanups.
      
      Note that current code which includes the platform specific headers
      only works because we transitively included macro-assembler.h already
      before.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8238, v8:7490
      Change-Id: I2dc65ad950400941406e1f2f8969d0d15f524bf8
      Reviewed-on: https://chromium-review.googlesource.com/c/1340240
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57578}
      1952f928
  22. 12 Nov, 2018 1 commit
  23. 05 Nov, 2018 1 commit
  24. 25 Oct, 2018 2 commits
  25. 19 Oct, 2018 1 commit
  26. 10 Oct, 2018 1 commit
  27. 02 Oct, 2018 1 commit
  28. 20 Sep, 2018 2 commits
  29. 15 Sep, 2018 1 commit
  30. 04 Sep, 2018 1 commit
  31. 27 Aug, 2018 1 commit
  32. 22 Aug, 2018 2 commits
  33. 08 Aug, 2018 3 commits
    • Junliang Yan's avatar
      PPC/s390: Reland "[turboassembler] Introduce hard-abort mode" · a27871d5
      Junliang Yan authored
      Port d324382e
      
      and
      
      Port bd3f0a68
      
      Original Commit Message:
      
          This is a reland of a462a785
      
          Original change's description:
          > [turboassembler] Introduce hard-abort mode
          >
          > For checks and assertions (mostly for debug code, like stack alignment
          > or zero extension), we had two modes: Emit a call to the {Abort}
          > runtime function (the default), and emit a debug break (used for
          > testing, enabled via --trap-on-abort).
          > In wasm, where we cannot just call a runtime function because code must
          > be isolate independent, we always used the trap-on-abort behaviour.
          > This causes problems for our fuzzers, which do not catch SIGTRAP, and
          > hence do not detect debug code failures.
          >
          > This CL introduces a third mode ("hard abort"), which calls a C
          > function via {ExternalReference}. The C function still outputs the
          > abort reason, but does not print the stack trace. It then aborts via
          > "OS::Abort", just like the runtime function.
          > This will allow fuzzers to detect the crash and even find a nice error
          > message.
          >
          > Even though this looks like a lot of code churn, it is actually not.
          > Most added lines are new tests, and other changes are minimal.
          >
          > R=mstarzinger@chromium.org
          >
          > Bug: chromium:863799
          > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
          > Reviewed-on: https://chromium-review.googlesource.com/1142163
          > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
          > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#54592}
      
      R=clemensh@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I60023470fa07576fd313f628ade06e279d5f4927
      Reviewed-on: https://chromium-review.googlesource.com/1165822
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54980}
      a27871d5
    • Michael Starzinger's avatar
      [cleanup] Remove some dead MacroAssembler declarations. · b6f525ae
      Michael Starzinger authored
      R=sigurds@chromium.org
      
      Change-Id: I7df887f84024831b4c55b3468bd54429280dd14e
      Reviewed-on: https://chromium-review.googlesource.com/1167054Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54977}
      b6f525ae
    • Michael Starzinger's avatar
      [cleanup] Unify {AreAliased} predicates. · da3c2db9
      Michael Starzinger authored
      R=sigurds@chromium.org
      
      Change-Id: I1ca0e215da36400a8817bc8c8912ccfde8eca613
      Reviewed-on: https://chromium-review.googlesource.com/1166911Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54973}
      da3c2db9