1. 14 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a CallFunctionTemplate builtin. · a2d9924c
      Benedikt Meurer authored
      When calling into API callbacks from TurboFan optimized, we can
      currently only take a fast-path when TurboFan is able to find some
      information about the receiver in the graph, or when the API callback
      specifies that it neither requires an access check (aka "accepts any
      receiver") nor an interface check (aka "compatible receiver check").
      
      This change introduces a new CallFunctionTemplate builtin that sits
      in front of the CallApiCallback builtin and does both the access as well
      as the interface check as necessary (and raises appropriate exceptions).
      This way TurboFan can still call into the API callback via the fast-path
      even without ahead knowledge about the receiver, which is significantly
      faster than the generic call machinery for API callbacks.
      
      On the test case from the Angular team[1], the interesting metrics
      improve from
      
        DOM_mono: 0.273 ms
        DOM_mega: 0.571 ms
        DOM_call: 0.649 ms
      
      to
      
        DOM_mono: 0.264 ms
        DOM_mega: 0.572 ms
        DOM_call: 0.368 ms
      
      so the DOM_call is only about **1.4 times slower** than the DOM_mono and
      about **1.5 times faster** than the DOM_mega case (compared to **2.4
      times slower**). Execution time in the DOM_call was reduced by around
      **~45%**.
      
      Currently this new code path is limited to TurboFan optimized code, but
      the idea is to eventually migrate the API calls from baseline to also
      use the new CSA functionality, but there are lot's of subleties to take
      into account, so starting with small changes to get coverage for the
      basic building blocks.
      
      [1]: https://mhevery.github.io/perf-tests/DOM-megamorphic.html
      
      Bug: v8:8820
      Change-Id: Ie1029cf182ce05a6e519fd9a9d4fa825db8adb4c
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/1470129
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59598}
      a2d9924c
  2. 13 Feb, 2019 2 commits
  3. 17 Jan, 2019 2 commits
  4. 16 Jan, 2019 1 commit
    • Jakob Gruber's avatar
      [nojit] Convert generated memcpy functions into builtins · 61cb1133
      Jakob Gruber authored
      On ia32, arm and mips we generate miscellaneous memcpy-related functions
      at runtime:
      
      arm: memcpy for uint8-uint8 and uint16-uint8 {dest-source} pairs.
      ia32: memmove
      mips: memcpy uint8-uint8
      
      In jitless mode, runtime codegen is disallowed, so these must be
      converted into builtins.
      
      As far as I can tell, the mips64 files were dead code (#ifdef'd to
      V8_HOST_ARCH_MIPS instead of MIPS64).
      
      Note also the slightly changed implementation of ia32's MemMove's
      jump tables.
      
      Bug: v8:8675
      Change-Id: I5dc2a50fcbad332ce9f78228425b987b0d9acdf3
      Reviewed-on: https://chromium-review.googlesource.com/c/1407067Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58839}
      61cb1133
  5. 15 Jan, 2019 1 commit
  6. 14 Jan, 2019 1 commit
    • Predrag Rudic's avatar
      MIPS[64] Fix floating point register allocation · ff7ced51
      Predrag Rudic authored
      Failure to make snapshot in debug mode on MIPS was caused by bad
      floating point register allocation for function parameters. According to
      MIPS convention, floating point parameters  cannot be stored on odd
      numbered floating point register. Which was the case (f7 was allocated).
      This patch ensures that f12 and f14 are used for storing fp parameters.
      
      To be able to determine types of parameters in InitializePlatformSpecific
      method, InitializePlatformIndependent has to be executed first.
      InitializePlatformIndependent requires number of parameters in arguments.
      That is the reason for changing definitions of CompareDescriptor and
      BinaryDescriptor classes.
      
      Change-Id: I7d723e03385f756114df60e33798400e97d99d8f
      Reviewed-on: https://chromium-review.googlesource.com/c/1400415Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Predrag Rudic <prudic@wavecomp.com>
      Cr-Commit-Position: refs/heads/master@{#58768}
      ff7ced51
  7. 19 Dec, 2018 1 commit
  8. 13 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [builtins] Associate ASM builtins with descriptors · e61d3564
      Jakob Gruber authored
      Post-stub-to-builtin migration, all explicit connection between
      descriptors and their associated ASM code has been lost. This restores
      the connection where possible. Builtins without an associated
      descriptor are marked with the DummyDescriptor.
      
      Drive-by: alpha-sort the descriptor list.
      Drive-by: use Builtins::CallableFor in code factory.
      
      Bug: v8:8562, v8:8553
      Change-Id: If1f13bbaf7e42453b3235cc97c58ada91b5fa7b8
      Reviewed-on: https://chromium-review.googlesource.com/c/1373552Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58212}
      e61d3564
  9. 11 Dec, 2018 2 commits
  10. 04 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Refactor CallApiCallback calling convention · c6b0e12e
      Jakob Gruber authored
      This is the first (and major) step towards converting CallApiCallback
      and CallApiGetter stubs into builtins.
      
      The CallApiCallbackStub was parameterized with the number of arguments
      passed on the stack. This CL converts the compile-time parameter into
      an explicit runtime parameter, and removes all uses of the stub
      parameter.
      
      Drive-by: The implementation is now mostly consistent across platforms.
      Drive-by: Refactor the calling convention to free up two registers
      (kCallData and kHolder are now passed on the stack).
      
      Bug: v8:7777
      Change-Id: I212dccc2930de89c264a13755918c9fae7842f1f
      Reviewed-on: https://chromium-review.googlesource.com/c/1354887
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58005}
      c6b0e12e
  11. 01 Dec, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Fix complaint in NewArray when size == 0 · 42180759
      Jakob Kummerow authored
      While strictly speaking it is legal (though useless) to dynamically
      create zero-length arrays with "new T[0]", UBSan does not like it,
      so this CL avoids doing it. It fixes the error:
      
      ../../src/allocation.h:41:34: runtime error: constructor call on
      address 0x... with insufficient space for an object of type 'unsigned char'
      
      Bug: v8:3770
      Change-Id: I5017767c59df0d8928f7493f92d2d04519083964
      Reviewed-on: https://chromium-review.googlesource.com/c/1356902Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57984}
      42180759
  12. 30 Nov, 2018 2 commits
  13. 29 Nov, 2018 1 commit
    • Aseem Garg's avatar
      Revert "[wasm] Add I64AtomicWait implementation" · f4775f1c
      Aseem Garg authored
      This reverts commit 9436e8a8.
      
      Reason for revert: Breaks TSAN.
      
      Original change's description:
      > [wasm] Add I64AtomicWait implementation
      > 
      > Bug=v8:8075
      > R=​adamk@chromium.org,binji@chromium.org
      > 
      > Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
      > Reviewed-on: https://chromium-review.googlesource.com/c/1342948
      > Reviewed-by: Adam Klein <adamk@chromium.org>
      > Reviewed-by: Ben Smith <binji@chromium.org>
      > Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57917}
      
      TBR=binji@chromium.org,adamk@chromium.org,aseemgarg@chromium.org
      
      Change-Id: Ic82ce8794410a0d4d19de07abd9bb8a7aaff1c1c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/1351303Reviewed-by: 's avatarAseem Garg <aseemgarg@chromium.org>
      Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57919}
      f4775f1c
  14. 28 Nov, 2018 1 commit
  15. 20 Nov, 2018 1 commit
  16. 19 Nov, 2018 2 commits
  17. 29 Oct, 2018 1 commit
  18. 23 Oct, 2018 1 commit
  19. 10 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Improve async function handling. · 0038e5f0
      Benedikt Meurer authored
      This change introduces new intrinsics used to desugar async functions
      in the Parser and the BytecodeGenerator, namely we introduce a new
      %_AsyncFunctionEnter intrinsic that constructs the generator object
      for the async function (and in the future will also create the outer
      promise for the async function). This generator object is internal
      and never escapes to user code, plus since async functions don't have
      a "prototype" property, we can just a single map here instead of tracking
      the prototype/initial_map on every async function. This saves one word
      per async function plus one initial_map per async function that was
      invoked at least once.
      
      We also introduce two new intrinsics %_AsyncFunctionReject, which
      rejects the outer promise with the caught exception, and another
      %_AsyncFunctionResolve, which resolves the outer promise with the
      right hand side of the `return` statement. These functions also perform
      the DevTools part of the job (aka popping from the promise stack and
      sending the debug event). This allows us to get rid of the implicit
      try-finally from async functions completely; because the finally
      block only called to the %AsyncFunctionPromiseRelease builtin, which
      was used to inform DevTools.
      
      In essence we now turn an async function like
      
      ```js
      async function f(x) { return await bar(x); }
      ```
      
      into something like this (in Parser and BytecodeGenerator respectively):
      
      ```
      function f(x) {
        .generator_object = %_AsyncFunctionEnter(.closure, this);
        .promise = %AsyncFunctionCreatePromise();
        try {
          .tmp = await bar(x);
          return %_AsyncFunctionResolve(.promise, .tmp);
        } catch (e) {
          return %_AsyncFunctionReject(.promise, e);
        }
      }
      ```
      
      Overall the bytecode for async functions gets significantly shorter
      already (and will get even shorter once we put the outer promise into
      the async function generator object). For example the bytecode for a
      simple async function
      
      ```js
      async function f(x) { return await x; }
      ```
      
      goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
      is in particular due to the simplification around the try-finally
      removal.
      
      Overall this seems to improve the doxbee-async-es2017-native test by
      around 2-3%. On the test case mentioned in v8:8276 we go from
      1124ms to 441ms, which corresponds to a 60% reduction in total
      execution time!
      
      Tbr: marja@chromium.org
      Bug: v8:7253, v8:7522, v8:8276
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
      Reviewed-on: https://chromium-review.googlesource.com/c/1269041
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56502}
      0038e5f0
  20. 25 Sep, 2018 1 commit
  21. 20 Sep, 2018 1 commit
  22. 14 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial Word64 support in representation selection. · 6346cdb6
      Benedikt Meurer authored
      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.
      
      Bug: v8:7881, v8:8015, v8:8171
      Design-Document: http://bit.ly/turbofan-word64
      Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1224932
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55886}
      6346cdb6
  23. 10 Sep, 2018 1 commit
  24. 03 Sep, 2018 3 commits
    • jgruber's avatar
      Ensure kRootRegister is unused in interface descriptors · 5b992f53
      jgruber authored
      Now that we've removed kRootRegister from all ia32 interface
      descriptors, let's make sure it does not sneak back in.
      
      Bug: v8:6666
      Change-Id: Ie3528908a142c36f106b0053041ed974216533d4
      Reviewed-on: https://chromium-review.googlesource.com/1202083
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55590}
      5b992f53
    • 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
    • jgruber's avatar
      [ia32] Pass InterpreterPushArgsThenConstruct args on the stack · 158216e9
      jgruber authored
      In preparation for kRootRegister support on ia32.
      
      Instead of pushing the register args first thing within the builtin to
      free up needed scratch registers, we just pass the last 3 arguments on
      the stack.
      
      Drive-by: Update documentation of helper function.
      
      Bug: v8:6666
      Change-Id: I4a194d6885ac9cdfb9f5e66d687522442fae39ba
      Reviewed-on: https://chromium-review.googlesource.com/1199025
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55585}
      158216e9
  25. 31 Aug, 2018 2 commits
    • jgruber's avatar
      Refactor InterpreterPushArgsThenConstruct · 85cd0d87
      jgruber authored
      This reorders arguments in preparation for removing ebx from its
      calling convention (in a follow-up some args will be passed on the
      stack).
      
      Drive-by: Improve readability in the code handling different cases
      (array,spread,...).
      
      Bug: v8:6666
      Change-Id: I0160f8efafd0fd0e841739578e01c32b38adb66e
      Reviewed-on: https://chromium-review.googlesource.com/1196884Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55557}
      85cd0d87
    • jgruber's avatar
      [ia32] Unalias kRootRegister in ApiCallback,InterpreterPushArgsThenCall · fdb31302
      jgruber authored
      In preparation for kRootRegister support on ia32.
      
      For both descriptors we simply shuffle registers around to remove ebx
      from the calling convention.
      
      Possible follow-up work: The ApiCallbackDescriptor could be simplified
      by passing call_data (and the Undefined constant) on the stack. This
      currently happens in the builtin body.
      
      Drive-by: Minor refactoring in InterpreterPushArgsMode to deobfuscate
      the different paths (spread/no-spread). Also use
      {Push,Pop}ReturnAddress helpers.
      
      Bug: v8:6666
      Change-Id: I25fd738501fff71c038a0745cec04363f90df660
      Reviewed-on: https://chromium-review.googlesource.com/1196552Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55554}
      fdb31302
  26. 29 Aug, 2018 2 commits
  27. 28 Aug, 2018 1 commit
  28. 24 Aug, 2018 1 commit
  29. 23 Aug, 2018 1 commit
  30. 20 Jul, 2018 1 commit
    • Caitlin Potter's avatar
      [runtime] use new CloneObject bytecode for some ObjectLiteralSpread cases · b6f7ea58
      Caitlin Potter authored
      As discussed in
      https://docs.google.com/document/d/1sBdGe8RHgeYP850cKSSgGABTyfMdvaEWLy-vertuTCo/edit?ts=5b3ba5cc#,
      
      this CL introduces a new bytecode (CloneObject), and a new IC type.
      
      In this prototype implementation, the type feedback looks like the
      following:
      
      Uninitialized case:
        { uninitialized_sentinel, uninitialized_sentinel }
      Monomorphic case:
        { weak 'source' map, strong 'result' map }
      Polymorphic case:
        { WeakFixedArray with { weak 'source' map, strong 'result' map }, cleared value }
      Megamorphic case:
        { megamorphic_sentinel, cleared_Value }
      
      In the fast case, Object cloning is done by allocating an object with
      the saved result map, and a shallow clone of the fast properties from
      the source object, as well as cloned fast elements from the source object.
      If at any point the fast case can't be taken, the IC transitions to the
      slow case and remains there.
      
      This prototype CL does not include any TurboFan optimization, and the
      CloneObject operation is merely reduced to a stub call.
      
      It may still be possible to get some further improvements by somehow
      incorporating compile-time boilerplate elements into the cloned object,
      or simplifying how the boilerplate elements are inserted into the
      object.
      
      In terms of performance, we improve the ObjectSpread score in JSTests/ObjectLiteralSpread/
      by about 8x, with substantial improvements over the Babel and ObjectAssign scores.
      
      R=gsathya@chromium.org, mvstanton@chromium.org, rmcilroy@chromium.org, neis@chromium.org, bmeurer@chromium.org
      BUG=v8:7611
      
      Change-Id: I79e1796eb77016fb4feba0e1d3bb9abb348c183e
      Reviewed-on: https://chromium-review.googlesource.com/1127472
      Commit-Queue: Caitlin Potter <caitp@igalia.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54595}
      b6f7ea58
  31. 22 Jun, 2018 1 commit