1. 13 Oct, 2017 6 commits
  2. 12 Oct, 2017 1 commit
    • Pierre Langlois's avatar
      [arm] Support splitting add with immediate instructions · d5b29f43
      Pierre Langlois authored
      When an immediate does not fit an add instruction we use a temporary register to
      hold the value, using movw/movt to encode it. However, in order to remove a use
      of r9 in TurboFan's code generator, we need to cope with no scratch registers
      being available. That is to say that the destination and source registers are
      the same, and `ip` is not available to use.
      
      In this case, we can split an add instruction into a sequence of additions:
      ```
      UseScratchRegisterScope temps(...);
      Register my_scratch = temps.Acquire();
      __ add(r0, r0, Operand(0xabcd); // add r0, r0, #0xcd
                                      // add r0, r0, #0xab00
      ```
      
      As a drive-by fix, make the disassembler test fail if we expected a different
      number of instructions generated.
      
      Bug: v8:6553
      Change-Id: Ib7fcc765d28bccafe39257f47cd73f922c5873bf
      Reviewed-on: https://chromium-review.googlesource.com/685014Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
      Cr-Commit-Position: refs/heads/master@{#48491}
      d5b29f43
  3. 11 Oct, 2017 1 commit
    • Georgia Kouveli's avatar
      [arm64] Update BuiltinContinuation frames for jssp alignment. · a63f045c
      Georgia Kouveli authored
      Adds some necessary padding to ensure the frame is 16-byte aligned.
      We don't yet consider the bailout state, which will be handled separately.
      
      This patch also improves the code generated for ContinueTo*Builtin* stubs.
      
      Finally, it adds a test that checks the return value for Array.map in
      the case where a LAZY deopt results in a topmost builtin continuation
      frame - this is easy to break if the padding for the result is done
      incorrectly in NotifyBuiltinContinuation, but was not detected by existing
      tests.
      
      Bug: v8:6644
      Change-Id: Id1a294950cdf535e2bfdb0ed27c67f077ec34f8a
      Reviewed-on: https://chromium-review.googlesource.com/704835
      Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48465}
      a63f045c
  4. 09 Oct, 2017 9 commits
  5. 04 Oct, 2017 1 commit
  6. 28 Sep, 2017 1 commit
  7. 25 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored
      When inlining based on SharedFunctionInfo rather than based on concrete
      JSFunction, we weren't able to properly optimize array, object and
      regexp literals inside the inlinee, because we didn't know the concrete
      FeedbackVector for the inlinee inside JSCreateLowering. This was because
      JSCreateLowering wasn't properly updated after the literals moved to the
      FeedbackVector. Now with this CL we also have the VectorSlotPair on the
      literal creation operators, just like we do for property accesses and
      calls, and are thus able to always access the appropriate FeedbackVector
      and optimize the literal creation.
      
      The impact is illustrated by the micro-benchmark on the tracking bug,
      which goes from
      
        createEmptyArrayLiteral: 1846 ms.
        createShallowArrayLiteral: 1868 ms.
        createShallowObjectLiteral: 2246 ms.
      
      to
      
        createEmptyArrayLiteral: 1175 ms.
        createShallowArrayLiteral: 1187 ms.
        createShallowObjectLiteral: 1195 ms.
      
      with this CL, so up to 2x faster now.
      
      Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
      and cleanup the names of the other builtins to be consistent with the
      names of the TurboFan operators and Ignition bytecodes.
      
      Bug: v8:6856
      Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
      Reviewed-on: https://chromium-review.googlesource.com/680656
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
  8. 22 Sep, 2017 2 commits
  9. 14 Sep, 2017 1 commit
  10. 13 Sep, 2017 1 commit
  11. 08 Sep, 2017 1 commit
  12. 07 Sep, 2017 1 commit
  13. 06 Sep, 2017 1 commit
    • Clemens Hammacher's avatar
      [assembler] Make Register et al. real classes · 9e995e12
      Clemens Hammacher authored
      Up to now, each architecture defined all Register types as structs,
      with lots of redundancy. An often found comment noted that they cannot
      be classes due to initialization order problems. As these problems are
      gone with C++11 constexpr constants, I now tried making Registers
      classes again.
      All register types now inherit from RegisterBase, which provides a
      default set of methods and named constructors (like ::from_code,
      code(), bit(), is_valid(), ...).
      This design allows to guarantee an interesting property: Each register
      is either valid, or it's the no_reg register. There are no other
      invalid registers. This is guaranteed statically by the constexpr
      constructor, and dynamically by ::from_code.
      
      I decided to disallow the default constructor completely, so instead of
      "Register reg;" you now need "Register reg = no_reg;". This makes
      explicit how the Register is initialized.
      
      I did this change to the x64, ia32, arm, arm64, mips and mips64 ports.
      Overall, code got much more compact and more safe. In theory, it should
      also increase performance (since the is_valid() check is simpler), but
      this is probably not measurable.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I5ccfa4050daf4e146a557970e9d37fd3d2788d4a
      Reviewed-on: https://chromium-review.googlesource.com/650927Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47847}
      9e995e12
  14. 05 Sep, 2017 1 commit
  15. 04 Sep, 2017 2 commits
  16. 01 Sep, 2017 1 commit
  17. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored
      This change adapts the Call bytecode handlers such that they don't require
      a stack frame. It does this by modifying the call bytecode handler to
      tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
      callee function will return to the InterpreterEntryTrampoline when it returns
      (since this is the return address on the interpreter frame), which is
      adapted to dispatch to the next bytecode handler. The return bytecode
      handler is modified to tail-call a new InterpreterExitTramoline instead
      of returning to the InterpreterEntryTrampoline.
      
      Overall this significanlty reduces the amount of stack space required for
      interpreter frames, increasing the maximum depth of recursive calls from
      around 6000 to around 12,500 on x64.
      
      BUG=chromium:753705
      
      Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
      Reviewed-on: https://chromium-review.googlesource.com/634364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
  18. 24 Aug, 2017 3 commits
  19. 23 Aug, 2017 2 commits
    • Ross McIlroy's avatar
      Reland "[Compiler] Remove code aging support." · 8bf15bf1
      Ross McIlroy authored
      > This reverts commit 42d3d36b.
      > 
      > Original change's description:
      > > [Compiler] Remove code aging support.
      > > 
      > > Code aging is no longer supported by any remaining compilers now
      > > that full codegen has been removed. This CL removes all vestiges of
      > > code aging.
      > > 
      > > BUG=v8:6409
      > > 
      > > Change-Id: I945ebcc20c7c55120550c8ee36188bfa042ea65e
      > > Reviewed-on: https://chromium-review.googlesource.com/619153
      > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Marja Hölttä <marja@chromium.org>
      > > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#47501}
      > 
      > TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      > 
      > Change-Id: I9d8b2985e2d472697908270d93a35eb7ef9c88a8
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6409
      > Reviewed-on: https://chromium-review.googlesource.com/625998
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47506}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,marja@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,rodolph.perfetta@arm.com
      
      Change-Id: I68785c6be7686e874b3848103e3a34483eaeb519
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6409
      Reviewed-on: https://chromium-review.googlesource.com/625919Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47535}
      8bf15bf1
    • Michael Starzinger's avatar
      [ic] Remove deprecated CompareIC stub support. · 10f73fac
      Michael Starzinger authored
      R=ishell@chromium.org
      BUG=v8:6409
      
      Change-Id: Ic01d4f1a8b251bb5480840d4943d9ebec713b9c1
      Reviewed-on: https://chromium-review.googlesource.com/626016Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47534}
      10f73fac
  20. 22 Aug, 2017 3 commits