1. 15 Feb, 2019 1 commit
  2. 28 Jan, 2019 1 commit
  3. 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
  4. 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
  5. 07 Jan, 2019 1 commit
  6. 03 Jan, 2019 2 commits
    • 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
  7. 02 Jan, 2019 2 commits
    • 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
    • Junliang Yan's avatar
      PPC/s390: [nojit] Migrate JSEntry variants to builtins · 65c11d39
      Junliang Yan authored
      Port b89d4249
      
      Original Commit Message:
      
          This migrates the JSEntryStub to three dedicated builtins:
      
          JSEntry
          JSConstructEntry
          JSRunMicrotasksEntry
      
          correct macro assembler method to load and store external references
          through the kRootRegister).
          kRootRegister is initialized, so we first reserve the slot and later
          load its value.
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ib84feca5e88d032307b5fab42377c56d074faf7f
      Reviewed-on: https://chromium-review.googlesource.com/c/1393296Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58503}
      65c11d39
  8. 11 Dec, 2018 1 commit
  9. 07 Dec, 2018 1 commit
  10. 05 Dec, 2018 1 commit
  11. 04 Dec, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 9583858e
      Junliang Yan authored
      Port 6c8b4102
      
      Original Commit Message:
      
          This is a reland of d5f4a33e
          Landing with test disabled for now.
      
          Original change's description:
          > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
          >
          > Before fast C calls, store the current FP and PC on the isolate. When
          > iterating frames in SafeStackFrameIterator, check if these fields are
          > set and start iterating at the calling frame's FP instead of the current
          > FP, which will be in C++ code. We need to do this because c_entry_fp is
          > not set on the Isolate for Fast-C-Calls because we don't build an exit
          > frame.
          >
          > This change makes stack samples that occur within 'Fast-C-Calls'
          > iterable, meaning we can properly attribute ticks within the JS caller.
          >
          > Fast-C-Calls can't call back into JS code, so we can only ever have one
          > such call on the stack at a time, allowing us to store the FP on the
          > isolate rather than the stack.
          >
          > TBR=v8-mips-ports@googlegroups.com
          >
          > Bug: v8:8464, v8:7202
          > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
          > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
          > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
          > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
          > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
          > Reviewed-by: Alexei Filippov <alph@chromium.org>
          > Cr-Commit-Position: refs/heads/master@{#57896}
      
      R=petermarshall@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ie82eaa08ba6ceeb0c0a5bb4de251540becf1f05e
      Reviewed-on: https://chromium-review.googlesource.com/c/1361422Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#58025}
      9583858e
  12. 26 Nov, 2018 1 commit
  13. 16 Nov, 2018 2 commits
  14. 13 Nov, 2018 1 commit
  15. 12 Nov, 2018 1 commit
  16. 09 Nov, 2018 1 commit
  17. 07 Nov, 2018 1 commit
  18. 06 Nov, 2018 1 commit
  19. 05 Nov, 2018 1 commit
  20. 25 Oct, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [wasm] Support encoding reference types in exceptions. · 199af662
      Junliang Yan authored
      Port e893eb14
      
      Original Commit Message:
      
          This adds support for having reference type values (i.e. anyref) stored
          in an exception. It is the natural combination of the reference type
          proposal and the exception handling proposal.
      
          Note that this also introduces support for having write barriers in
          generated WasmCode, as this is the first time we are storing references
          within generated code. Such write barriers will be needed for other uses
          of reference types (e.g. mutable global) regardless.
      
      R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=v8:8341
      LOG=N
      
      Change-Id: I6837a31791654ebe4171f6ecb563939beb3a66dd
      Reviewed-on: https://chromium-review.googlesource.com/c/1299899Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#57009}
      199af662
  21. 17 Oct, 2018 1 commit
  22. 11 Oct, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [async] Introduce dedicated JSAsyncFunctionObject. · 71898faf
      Junliang Yan authored
      Port a63987a4
      
      Original Commit Message:
      
          This JSAsyncFunctionObject represents the implicit generator object
          inside of async functions, and also holds the outer promise for the
          async functions. This in turn allows us to get rid of the .promise
          in the Parser / BytecodeGenerator completely, and will make it
          possible to build zero-cost async stack traces independent of the
          concrete synchronous part of the stack frame (which currently breaks
          in Node.js).
      
          In the bytecode all the async function operations now take this new
          JSAsyncFunctionObject instead of passing both the .generator_object
          and the .promise, which further simplifies and shrinks the bytecode.
          It also reduces the size of async function frames, potentially making
          the suspend/resume cheaper.
      
          This also changes `await` to use intrinsics instead of calling to
          special JSFunctions on the native context, and thus reduces the size of
          the native contexts.
      
          to TurboFan.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ife0aa45b11580f316e657942485907cf78336e4b
      Reviewed-on: https://chromium-review.googlesource.com/c/1276867
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#56581}
      71898faf
  23. 10 Oct, 2018 1 commit
  24. 02 Oct, 2018 1 commit
  25. 20 Sep, 2018 1 commit
  26. 03 Sep, 2018 1 commit
    • jgruber's avatar
      Remove isolate parameter from RecordWrite builtin · 62766423
      jgruber authored
      The isolate can be efficiently loaded through other means: either as a
      root-relative load (if embedded builtins are enabled), or as an embedded
      external reference (i.e. the absolute pointer is included in the
      instruction stream) otherwise.
      
      The generated code should be at least as fast as previously. On x64
      (with embedded builtins):
      
      Before:
       // Register moves in prologue:
       0x7f47a6b4860a     a  488955e0       REX.W movq [rbp-0x20],rdx
       // And the load from a stack slot at each use-site.
       0x7f47a6b486f2    f2  488b7de0       REX.W movq rdi,[rbp-0x20]
      
      After:
       // Each use-site just loads a root-relative offset.
       0x7f1645fcc6ce    ee  498dbd38ffffff REX.W leaq rdi,[r13-0xc8]
      
      On ia32 (no embedded builtins), before:
       0x5c608930    10  8955f0         mov [ebp-0x10],edx
       0x5c6089fb    db  891424         mov [esp],edx
      
      After:
       0x41d0898d    8d  b80033b156     mov eax,0x56b13300
      
      Removal reduces register pressure, and frees up ebx as the root register
      on ia32.
      
      Note that the set of allocatable registers was only reduced on ia32 to
      exclude the root register.
      
      Bug: v8:6666
      Change-Id: I14e401e2823c82042c76acae10c3c935b9982993
      Reviewed-on: https://chromium-review.googlesource.com/1201586
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55587}
      62766423
  27. 27 Aug, 2018 1 commit
  28. 22 Aug, 2018 1 commit
  29. 15 Aug, 2018 1 commit
  30. 08 Aug, 2018 2 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] 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
  31. 02 Aug, 2018 1 commit
  32. 26 Jul, 2018 1 commit
  33. 25 Jul, 2018 3 commits
  34. 24 Jul, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "[turboassembler] Introduce hard-abort mode" · d324382e
      Clemens Hammacher authored
      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}
      
      Bug: chromium:863799
      Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
      Reviewed-on: https://chromium-review.googlesource.com/1146100Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54656}
      d324382e