1. 17 Feb, 2021 1 commit
    • Seth Brenith's avatar
      Reland "[interpreter] Short Star bytecode" · 7be64db4
      Seth Brenith authored
      This is a reland of cf93071c
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72821}
      7be64db4
  2. 16 Feb, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "[interpreter] Short Star bytecode" · 08a49bbe
      Leszek Swirski authored
      This reverts commit cf93071c.
      
      Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview
      
      Original change's description:
      > [interpreter] Short Star bytecode
      >
      > Design doc:
      > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      >
      > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      > that we can use a single byte to represent the common operation of
      > storing to a low-numbered register. This generally reduces the quantity
      > of bytecode generated on web sites by 8-9%.
      >
      > In order to not degrade speed, a couple of other changes are required:
      >
      > The existing lookahead logic to check for Star after certain other
      > bytecode handlers is updated to check for these new short Star codes
      > instead. Furthermore, that lookahead logic is updated to contain its own
      > copy of the dispatch jump rather than merging control flow with the
      > lookahead-failed case, to improve branch prediction.
      >
      > A bunch of constants use bytecode size in bytes as a proxy for the size
      > or complexity of a function, and are adjusted downward proportionally to
      > the decrease in generated bytecode size.
      >
      > Other small drive-by fix: update generate-bytecode-expectations to emit
      > \n instead of \r\n on Windows.
      >
      > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Cr-Commit-Position: refs/heads/master@{#72773}
      
      TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72777}
      08a49bbe
    • Seth Brenith's avatar
      [interpreter] Short Star bytecode · cf93071c
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
      
      This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
      that we can use a single byte to represent the common operation of
      storing to a low-numbered register. This generally reduces the quantity
      of bytecode generated on web sites by 8-9%.
      
      In order to not degrade speed, a couple of other changes are required:
      
      The existing lookahead logic to check for Star after certain other
      bytecode handlers is updated to check for these new short Star codes
      instead. Furthermore, that lookahead logic is updated to contain its own
      copy of the dispatch jump rather than merging control flow with the
      lookahead-failed case, to improve branch prediction.
      
      A bunch of constants use bytecode size in bytes as a proxy for the size
      or complexity of a function, and are adjusted downward proportionally to
      the decrease in generated bytecode size.
      
      Other small drive-by fix: update generate-bytecode-expectations to emit
      \n instead of \r\n on Windows.
      
      Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72773}
      cf93071c
  3. 11 Feb, 2021 1 commit
  4. 28 Jan, 2021 1 commit
  5. 08 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [interpreter] Include Star lookahead for more bytecodes · 0d30fac2
      Seth Brenith authored
      I made some temporary changes in BytecodeArrayWriter to log counts of
      how often each pair of bytecodes is adjacent. In data I collected on a
      Facebook page with those changes enabled, I noticed that the following
      bytecodes were commonly followed by Star, but do not appear in
      IsStarLookahead.
      
      LdaImmutableCurrentContextSlot:
        4.4% of all instructions, 66% chance to be followed by Star
      CreateClosure:
        3.9% of all instructions, 57% chance to be followed by Star
      LdaImmutableContextSlot:
        1.7% of all instructions, 95% chance to be followed by Star
      CreateObjectLiteral:
        1.4% of all instructions, 92% chance to be followed by Star
      CreateArrayLiteral:
        1.4% of all instructions, 99% chance to be followed by Star
      ThrowReferenceErrorIfHole:
        0.7% of all instructions, 100% chance to be followed by Star
      GetTemplateObject:
        0.6% of all instructions, 100% chance to be followed by Star
      CreateEmptyArrayLiteral:
        0.4% of all instructions, 87% chance to be followed by Star
      CreateEmptyObjectLiteral:
        0.2% of all instructions, 79% chance to be followed by Star
      
      I cross-referenced this list with data from google.com and youtube.com
      (the top two sites according to Alexa), and found that CreateClosure and
      CreateEmpty*Literal are not likely followed by Star on those sites.
      Without those three, I suggest that the following bytecode handlers
      would likely benefit from Star lookahead:
      
      LdaImmutableCurrentContextSlot
      LdaImmutableContextSlot
      CreateObjectLiteral
      CreateArrayLiteral
      ThrowReferenceErrorIfHole
      GetTemplateObject
      
      I also ran Octane with --noopt and got the following results.
      
      Name               Median change (95% CI)    U test result
      -----------------  ------------------------  -------------------
      Richards           +1.02% to +3.28%          improved  p=1.8e-05
      DeltaBlue          -1.47% to +0.12%          regressed p=0.05
      Crypto             -1.11% to +0.93%          inconclusive
      RayTrace           -1.10% to +0.48%          inconclusive
      EarleyBoyer        -0.25% to +1.29%          inconclusive
      RegExp             -1.46% to +0.08%          inconclusive
      Splay              -1.10% to +0.03%          inconclusive
      SplayLatency       +0.13% to +0.92%          improved  p=5.8e-05
      NavierStokes       -0.22% to +1.24%          inconclusive
      PdfJS              -0.69% to +1.04%          inconclusive
      Mandreel           -0.66% to +0.66%          inconclusive
      MandreelLatency    +0.32% to +1.77%          improved  p=0.00024
      Gameboy            -1.13% to +0.38%          inconclusive
      CodeLoad           -0.27% to +0.43%          inconclusive
      Box2D              -0.53% to +0.82%          inconclusive
      zlib               -0.19% to +0.19%          inconclusive
      Typescript         -0.23% to +0.59%          inconclusive
      Score (version 9)  -0.18% to +0.68%          inconclusive
      
      I'm somewhat puzzled by the DeltaBlue regression, since DeltaBlue
      agrees that all of the selected bytecodes are likely to precede Star,
      but overall I think this change is more benefit than harm.
      
      Change-Id: Ib9b4033f3cda273e99c9f0252d0055e203921916
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2615946Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#71987}
      0d30fac2
  6. 06 Sep, 2019 1 commit
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored
      This is a reland of 8b89a7c3
      
      Reland after disabling the test getting deadlocked with '--gc_stress' flag.
      The CL was reverted because of the 'wasm/grow-shared-memory' test from
      the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
      the known issue (v8:9221) and the deadlocking test is now disabled (
      https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).
      
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      >
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      >
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      Bug: v8:9489,v8:9221
      Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
  7. 03 Sep, 2019 2 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored
      This reverts commit 8b89a7c3.
      
      Reason for revert: GC Stress tests timing out.
      See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      > 
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      > 
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
      
      Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9489
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored
      The functionality of the GetIterator bytecode introduced previously is
      now extended from loading the @@iterator property to calling the property
      as well. This change basically absorbs the functionality of additional
      two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      Importantly, this change handles the cases of eager and lazy deoptimization
      in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      This mechanism can work as a template for the future bytecode that require
      handling such inter-bytecode deopt scenario. The tests evaluating the eager
      and lazy deopt scenarios are also included.
      
      Bug: v8:9489
      Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3
  8. 17 Sep, 2018 1 commit
  9. 10 Sep, 2018 1 commit
    • Dan Elphick's avatar
      [embedded handlers] Store the handlers without gaps · 5a9f0556
      Dan Elphick authored
      Previously the builtins table had a value for every single
      OperandScale/Bytecode combination regardless of whether it was valid.
      This change makes it so that only valid bytecode handlers are stored in
      the builtins table. This prevents placeholders being serialized into the
      snapshot (and embedded into the binary) saving 9KB in
      CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66
      entries in the builtins table.
      
      To do this, it generates a new header file bytecodes-builtins-list.h
      which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros.
      Since list macros cannot be used to conditionally generate elements in
      the C-preprocessor, this is done by generator executable, compiled from
      interpreter/generate-flat-headers.cc.
      
      Additionally the generator creates the flat bytecode list so that it is
      transposed from the previous result, i.e. the results are grouped by
      bytecode and then operand scale rather than operand scale then bytecode.
      This should give better locality for commonly used bytecodes and may
      allow less commonly used ExtraWide bytecodes to never be mapped into
      memory at all.
      
      The cost to storing the handlers densely is that looking up a handler
      now requires a binary search through the builtins table, but this should
      only happen during debugging. It is also fixable at least for non-wide
      handlers and could be improved for wide ones if the need arises.
      
      Bug: v8:8068
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667
      Reviewed-on: https://chromium-review.googlesource.com/1209304
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55757}
      5a9f0556
  10. 26 Jan, 2018 1 commit
  11. 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
  12. 26 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · 777da354
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46229}
      777da354
  13. 25 Jun, 2017 1 commit
  14. 23 Jun, 2017 1 commit
    • hans's avatar
      Make some functions that are hit during renderer startup available for inlining · d00d52be
      hans authored
      This is towards closing the perf gap between the MSVC build (which uses link-
      time optimization) and Clang (where LTO isn't ready on Windows yet). We did
      a study (see bug) to see which non-inlined functions are hit a lot during render
      start-up, and which would be inlined during LTO. This should benefit performance
      in all builds which currently don't use LTO (Android, Linux, Mac) as well as
      the Win/Clang build.
      
      The binary size of chrome_child.dll increases by 2KB with this.
      
      BUG=chromium:728324
      
      Review-Url: https://codereview.chromium.org/2950993002
      Cr-Commit-Position: refs/heads/master@{#46191}
      d00d52be
  15. 22 May, 2017 1 commit
  16. 11 Apr, 2017 2 commits
  17. 10 Apr, 2017 1 commit
    • Leszek Swirski's avatar
      [ignition] Add call bytecodes for undefined receiver · 751e8935
      Leszek Swirski authored
      Adds a collection of call bytecodes which have an implicit undefined
      receiver argument, for cases such as global calls where we know that the
      receiver has to be undefined. This way we can skip an LdaUndefined,
      decrease bytecode register pressure, and set a more accurate
      ConvertReceiverMode on the interpreter and TurboFan call.
      
      As a side effect, the "normal" Call bytecode now becomes a rare case
      (only with calls and super property calls), so we get rid of its 0-2
      argument special cases and modify CallProperty[N] to use the
      NotNullOrUndefined ConvertReceiverMode.
      
      Change-Id: I9374a32fefd66fc0251b5193bae7a6b7dc31eefc
      Reviewed-on: https://chromium-review.googlesource.com/463287
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44530}
      751e8935
  18. 16 Feb, 2017 1 commit
    • Daniel Clifford's avatar
      [ignition] Optimize reloading of registers before Dispatch · bd21c2bd
      Daniel Clifford authored
      Before this patch, the registers needed for bytecode dispatch in interpreter
      handlers were inconsistently stored in the interpreter frame and/or kept in
      values that remained live across calls.
      
      After this patch, these registers are explicitly reloaded after calls, making it
      possible to elide the spills of those registers before the call in many cases.
      
      Some highlights from the CL:
      
      * Added methods to the CSA and InterpreterAssembler to efficiently store and
        load Smis values and Smi interpreter registers on x64 without explicit
        tagging/untagging.
      
      * Created Variables for all of the interpreter-internal values that need to be
        reloaded before bytecode dispatch at the end of an interpreter handler.
      
      * The bytecode offset can be written out early in a handler by marking it
        has having a call along it's critical path. By moving this early in a
        handler, it becomes possible to use memory operands for pushes used to
        marshall parameters when making calls.
      
      Change-Id: Icf8d7798789f88a4489e06a7092616bbbb881577
      Reviewed-on: https://chromium-review.googlesource.com/442566
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43260}
      bd21c2bd
  19. 01 Feb, 2017 1 commit
  20. 10 Nov, 2016 1 commit
  21. 09 Nov, 2016 1 commit
  22. 27 Oct, 2016 1 commit
    • leszeks's avatar
      [ignition] Add a property call bytecode · c4d770b1
      leszeks authored
      This is a new bytecode which behaves (for now) exactly like Call,
      except that in turbofan graph building we can set the
      ConvertReceiverMode to NotNullOrUndefined.
      
      I observe a 1% improvement on Box2D, I'd expect a similar improvement on
      other OOP heavy code.
      
      Review-Url: https://codereview.chromium.org/2450243002
      Cr-Commit-Position: refs/heads/master@{#40610}
      c4d770b1
  23. 22 Sep, 2016 2 commits
    • rmcilroy's avatar
      [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. · e5ac75c6
      rmcilroy authored
      This CL optimizes the code in BytecodeArrayBuilder and
      BytecodeArrayWriter by making the following main changes:
      
       - Move operand scale calculation out of BytecodeArrayWriter to the
      BytecodeNode constructor, where the decision on which operands are
      scalable can generally be statically decided by the compiler.
       - Move the maximum register calculation out of BytecodeArrayWriter
      and into BytecodeRegisterOptimizer (which is the only place outside
      BytecodeGenerator which updates which registers are used). This
      avoids the BytecodeArrayWriter needing to know the operand types
      of a node as it writes it.
       - Modify EmitBytecodes to use individual push_backs rather than
      building a buffer and calling insert, since this turns out to be faster.
       - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
      bytes,
       - Make common functions in Bytecodes constexpr so that they
      can be statically calculated by the compiler.
       - Move common functions and constructors in Bytecodes and
      BytecodeNode to the header so that they can be inlined.
       - Change large static switch statements in Bytecodes to const array
      lookups, and move to the header to allow inlining.
      
      I also took the opportunity to remove a number of unused helper
      functions, and rework some others for consistency.
      
      This reduces the percentage of time spent in making BytecodeArrays
       in  CodeLoad from ~15% to ~11% according to perf. The
      CoadLoad score increase by around 2%.
      
      BUG=v8:4280
      
      Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
      Review-Url: https://codereview.chromium.org/2351763002
      Cr-Original-Commit-Position: refs/heads/master@{#39599}
      Cr-Commit-Position: refs/heads/master@{#39637}
      e5ac75c6
    • hablich's avatar
      Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.... · 5d693348
      hablich authored
      Revert of [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. (patchset #6 id:200001 of https://codereview.chromium.org/2351763002/ )
      
      Reason for revert:
      Prime suspect for roll blocker: https://codereview.chromium.org/2362503002/
      
      Original issue's description:
      > [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter.
      >
      > This CL optimizes the code in BytecodeArrayBuilder and
      > BytecodeArrayWriter by making the following main changes:
      >
      >  - Move operand scale calculation out of BytecodeArrayWriter to the
      > BytecodeNode constructor, where the decision on which operands are
      > scalable can generally be statically decided by the compiler.
      >  - Move the maximum register calculation out of BytecodeArrayWriter
      > and into BytecodeRegisterOptimizer (which is the only place outside
      > BytecodeGenerator which updates which registers are used). This
      > avoids the BytecodeArrayWriter needing to know the operand types
      > of a node as it writes it.
      >  - Modify EmitBytecodes to use individual push_backs rather than
      > building a buffer and calling insert, since this turns out to be faster.
      >  - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
      > bytes,
      >  - Make common functions in Bytecodes constexpr so that they
      > can be statically calculated by the compiler.
      >  - Move common functions and constructors in Bytecodes and
      > BytecodeNode to the header so that they can be inlined.
      >  - Change large static switch statements in Bytecodes to const array
      > lookups, and move to the header to allow inlining.
      >
      > I also took the opportunity to remove a number of unused helper
      > functions, and rework some others for consistency.
      >
      > This reduces the percentage of time spent in making BytecodeArrays
      >  in  CodeLoad from ~15% to ~11% according to perf. The
      > CoadLoad score increase by around 2%.
      >
      > BUG=v8:4280
      >
      > Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64
      > Cr-Commit-Position: refs/heads/master@{#39599}
      
      TBR=mythria@chromium.org,leszeks@chromium.org,rmcilroy@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2360193003
      Cr-Commit-Position: refs/heads/master@{#39612}
      5d693348
  24. 21 Sep, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. · b11a8b4d
      rmcilroy authored
      This CL optimizes the code in BytecodeArrayBuilder and
      BytecodeArrayWriter by making the following main changes:
      
       - Move operand scale calculation out of BytecodeArrayWriter to the
      BytecodeNode constructor, where the decision on which operands are
      scalable can generally be statically decided by the compiler.
       - Move the maximum register calculation out of BytecodeArrayWriter
      and into BytecodeRegisterOptimizer (which is the only place outside
      BytecodeGenerator which updates which registers are used). This
      avoids the BytecodeArrayWriter needing to know the operand types
      of a node as it writes it.
       - Modify EmitBytecodes to use individual push_backs rather than
      building a buffer and calling insert, since this turns out to be faster.
       - Initialize BytecodeArrayWriter's bytecode vector by reserving 512
      bytes,
       - Make common functions in Bytecodes constexpr so that they
      can be statically calculated by the compiler.
       - Move common functions and constructors in Bytecodes and
      BytecodeNode to the header so that they can be inlined.
       - Change large static switch statements in Bytecodes to const array
      lookups, and move to the header to allow inlining.
      
      I also took the opportunity to remove a number of unused helper
      functions, and rework some others for consistency.
      
      This reduces the percentage of time spent in making BytecodeArrays
       in  CodeLoad from ~15% to ~11% according to perf. The
      CoadLoad score increase by around 2%.
      
      BUG=v8:4280
      
      Review-Url: https://codereview.chromium.org/2351763002
      Cr-Commit-Position: refs/heads/master@{#39599}
      b11a8b4d
  25. 20 Sep, 2016 1 commit
  26. 13 Sep, 2016 1 commit
    • mstarzinger's avatar
      [interpreter] Merge {OsrPoll} with {Jump} bytecode. · c9864173
      mstarzinger authored
      This introduces a new {JumpLoop} bytecode to combine the OSR polling
      mechanism modeled by {OsrPoll} with the actual {Jump} performing the
      backwards branch. This reduces the overall size and also avoids one
      additional dispatch. It also makes sure that OSR polling is only done
      within real loops.
      
      R=rmcilroy@chromium.org
      BUG=v8:4764
      
      Review-Url: https://codereview.chromium.org/2331033002
      Cr-Commit-Position: refs/heads/master@{#39384}
      c9864173
  27. 06 Sep, 2016 1 commit
  28. 29 Aug, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Remove special JSForInStep and JSForInDone. · 1915762c
      bmeurer authored
      These JavaScript operators were special hacks to ensure that we always
      operate on Smis for the magic for-in index variable, but this never
      really worked in the OSR case, because the OsrValue for the index
      variable didn't have the proper information (that we have for the
      JSForInPrepare in the non-OSR case).
      
      Now that we have loop induction variable analysis and binary operation
      hints, we can just use JSLessThan and JSAdd instead with appropriate
      Smi hints, which handle the OSR case by inserting Smi checks (that are
      always true). Thanks to OSR deconstruction and loop peeling these Smi
      checks will be hoisted so they don't hurt the OSR case too much.
      
      Drive-by-change: Rename the ForInDone bytecode to ForInContinue, since
      we have to lower it to JSLessThan to get the loop induction variable
      goodness.
      
      R=epertoso@chromium.org
      BUG=v8:5267
      
      Review-Url: https://codereview.chromium.org/2289613002
      Cr-Commit-Position: refs/heads/master@{#38968}
      1915762c
  29. 25 Jul, 2016 1 commit
  30. 20 Jul, 2016 1 commit
  31. 19 Jul, 2016 1 commit
  32. 18 Jul, 2016 2 commits
  33. 15 Jul, 2016 1 commit
  34. 14 Jul, 2016 1 commit
  35. 13 Jul, 2016 1 commit