1. 27 Aug, 2021 1 commit
    • Leszek Swirski's avatar
      [sparkplug] Clobber accumulator in StaGlobal · 732f394c
      Leszek Swirski authored
      StaGlobal didn't write the accumulator, but the baseline implementation
      assumed that it could preserve the accumulator by taking the return
      value of the StoreGlobalIC. This almost always worked, except for
      setters on the global object.
      
      Fix this by marking StaGlobal as clobbering the accumulator, same as
      StaNamedProperty (StaNamedProperty needs to do this anyway to avoid
      inlined setters from needing to create accumulator-preserving frames;
      StaGlobal would have needed the same thing if we'd ever inlined setters
      for it).
      
      Also, add a new debug scope, EnsureAccumulatorPreservedScope, to the
      baseline compiler, which checks if the accumulator value is preserved
      across non-accumulator-writing bytecodes. This found a (benign) bug with
      ForInPrepare, so fix that too.
      
      Fixed: chromium:1242306
      Change-Id: I220b5b1c41010c16ac9f944cbd55d2705c299434
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122325
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76525}
      732f394c
  2. 18 Aug, 2021 1 commit
  3. 13 Aug, 2021 1 commit
    • Nicolò Ribaudo's avatar
      [class] Improve errors for reinitialized private elements · b3b9466a
      Nicolò Ribaudo authored
      Previously V8 was reusing the error fur duplicate declarations, using
      the private name for class fields or the class name for class methods
      as the redeclared identifier.
      
          class A { constructor(o) { return o } }
          class B extends A { #x }
          class C extends A { #x() {} }
          let D = (0, class extends A { #x() {} });
      
          new B(new B({})) // Identifier '#x' has already been declared
          new C(new C({})) // Identifier 'C' has already been declared
          new D(new D({})) // Identifier '' has already been declared
      
      This patch changes it to use error messages that better explain what's
      happening:
      
          new B(new B({})) // Cannot initialize #x twice on the same object
          new C(new C({})) // Cannot initialize private methods of
                           // class C twice on the same object
          new D(new D({})) // Cannot initialize private methods of
                           // class anonymous twice on the same object
      
      I initially tried to use the same message for both fields and methods,
      but the problem with that is that when initializing fields we only
      have access to the field name, while when initializing methods we only
      have access to the class name (using the "private brand" symbol).
      However, almost all the error messages are different for private fields
      and for methods so this shouldn't be a problem.
      
      Bug: v8:12042
      Change-Id: Iaa50c16e4fa5c0646ad9ef2aa7e65bb649b3fce2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3078362Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJoyee Cheung <joyee@igalia.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76279}
      b3b9466a
  4. 08 Jul, 2021 2 commits
    • Patrick Thier's avatar
      Reland "Reland "Reland "Improve error messages for property access on null/undefined""" · c0fd89c3
      Patrick Thier authored
      This is a reland of 819c3ae2
      
      Original change's description:
      > Reland "Reland "Improve error messages for property access on null/undefined""
      >
      > This is a reland of 8b18c5e6
      >
      > Original change's description:
      > > Reland "Improve error messages for property access on null/undefined"
      > >
      > > This is a reland of 24c626c1
      > >
      > > Original change's description:
      > > > Improve error messages for property access on null/undefined
      > > >
      > > > Only print the property name when accessing null/undefined if we can
      > > > convert it to a string without causing side effects.
      > > > If we can't, omit the property name in the error message.
      > > > This should avoid confusion when the key is an object with toString().
      > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > > Object]' anymore, which was misleading since the property accessed would
      > > > be 'a', but we can't evaluate the key without side effects.
      > > >
      > > > Bug: v8:11365
      > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#75250}
      > >
      > > Bug: v8:11365
      > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75571}
      >
      > Bug: v8:11365
      > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75604}
      
      Bug: v8:11365
      Change-Id: I002b537144f328ccbbdcd655e26e5dc87c49c6f5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013935Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75645}
      c0fd89c3
    • Leszek Swirski's avatar
      Revert "Reland "Reland "Improve error messages for property access on null/undefined""" · 7ac7b72b
      Leszek Swirski authored
      This reverts commit 819c3ae2.
      
      Reason for revert: Sorry Patrick, still failing on some layout tests :( https://test-results.appspot.com/data/layout_results/mac-rel/726365/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
      
      Original change's description:
      > Reland "Reland "Improve error messages for property access on null/undefined""
      >
      > This is a reland of 8b18c5e6
      >
      > Original change's description:
      > > Reland "Improve error messages for property access on null/undefined"
      > >
      > > This is a reland of 24c626c1
      > >
      > > Original change's description:
      > > > Improve error messages for property access on null/undefined
      > > >
      > > > Only print the property name when accessing null/undefined if we can
      > > > convert it to a string without causing side effects.
      > > > If we can't, omit the property name in the error message.
      > > > This should avoid confusion when the key is an object with toString().
      > > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > > Object]' anymore, which was misleading since the property accessed would
      > > > be 'a', but we can't evaluate the key without side effects.
      > > >
      > > > Bug: v8:11365
      > > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#75250}
      > >
      > > Bug: v8:11365
      > > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75571}
      >
      > Bug: v8:11365
      > Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      > Auto-Submit: Patrick Thier <pthier@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75604}
      
      Bug: v8:11365
      Change-Id: I7d7c0f201288384c2aa38a51418b582a64213ae0
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013352
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#75626}
      7ac7b72b
  5. 07 Jul, 2021 1 commit
    • Patrick Thier's avatar
      Reland "Reland "Improve error messages for property access on null/undefined"" · 819c3ae2
      Patrick Thier authored
      This is a reland of 8b18c5e6
      
      Original change's description:
      > Reland "Improve error messages for property access on null/undefined"
      >
      > This is a reland of 24c626c1
      >
      > Original change's description:
      > > Improve error messages for property access on null/undefined
      > >
      > > Only print the property name when accessing null/undefined if we can
      > > convert it to a string without causing side effects.
      > > If we can't, omit the property name in the error message.
      > > This should avoid confusion when the key is an object with toString().
      > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > Object]' anymore, which was misleading since the property accessed would
      > > be 'a', but we can't evaluate the key without side effects.
      > >
      > > Bug: v8:11365
      > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75250}
      >
      > Bug: v8:11365
      > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75571}
      
      Bug: v8:11365
      Change-Id: I90360641ecd870bd93247aa6d91dfb0ad049cfb8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008219
      Auto-Submit: Patrick Thier <pthier@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75604}
      819c3ae2
  6. 06 Jul, 2021 2 commits
    • Leszek Swirski's avatar
      Revert "Reland "Improve error messages for property access on null/undefined"" · 94cd8b64
      Leszek Swirski authored
      This reverts commit 8b18c5e6.
      
      Reason for revert: Still failing: https://test-results.appspot.com/data/layout_results/V8_Blink_Linux/12469/blink_web_tests%20%28retry%20shards%20with%20patch%29/layout-test-results/results.html
      
      Original change's description:
      > Reland "Improve error messages for property access on null/undefined"
      >
      > This is a reland of 24c626c1
      >
      > Original change's description:
      > > Improve error messages for property access on null/undefined
      > >
      > > Only print the property name when accessing null/undefined if we can
      > > convert it to a string without causing side effects.
      > > If we can't, omit the property name in the error message.
      > > This should avoid confusion when the key is an object with toString().
      > > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > > Object]' anymore, which was misleading since the property accessed would
      > > be 'a', but we can't evaluate the key without side effects.
      > >
      > > Bug: v8:11365
      > > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#75250}
      >
      > Bug: v8:11365
      > Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75571}
      
      Bug: v8:11365
      Change-Id: Ic4137f0d70fa9b10ca70fa921b98ea7e1499f11b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3008217
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#75577}
      94cd8b64
    • Patrick Thier's avatar
      Reland "Improve error messages for property access on null/undefined" · 8b18c5e6
      Patrick Thier authored
      This is a reland of 24c626c1
      
      Original change's description:
      > Improve error messages for property access on null/undefined
      >
      > Only print the property name when accessing null/undefined if we can
      > convert it to a string without causing side effects.
      > If we can't, omit the property name in the error message.
      > This should avoid confusion when the key is an object with toString().
      > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > Object]' anymore, which was misleading since the property accessed would
      > be 'a', but we can't evaluate the key without side effects.
      >
      > Bug: v8:11365
      > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75250}
      
      Bug: v8:11365
      Change-Id: Ie2312337f4f1915faa31528a728d90833d80dbd1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979599Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75571}
      8b18c5e6
  7. 21 Jun, 2021 1 commit
    • Bill Budge's avatar
      Revert "Improve error messages for property access on null/undefined" · b261213f
      Bill Budge authored
      This reverts commit 24c626c1.
      
      Reason for revert: Blocks V8 roll into Chromium (changed error messages cause tests to fail):
      https://ci.chromium.org/p/chromium/builders/try/linux-rel/724109?
      
      Original change's description:
      > Improve error messages for property access on null/undefined
      >
      > Only print the property name when accessing null/undefined if we can
      > convert it to a string without causing side effects.
      > If we can't, omit the property name in the error message.
      > This should avoid confusion when the key is an object with toString().
      > E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      > Object]' anymore, which was misleading since the property accessed would
      > be 'a', but we can't evaluate the key without side effects.
      >
      > Bug: v8:11365
      > Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Patrick Thier <pthier@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75250}
      
      Bug: v8:11365
      Change-Id: Ic63f34033254f55b3871041633d84ea48586a75d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2977374
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75282}
      b261213f
  8. 18 Jun, 2021 1 commit
    • Patrick Thier's avatar
      Improve error messages for property access on null/undefined · 24c626c1
      Patrick Thier authored
      Only print the property name when accessing null/undefined if we can
      convert it to a string without causing side effects.
      If we can't, omit the property name in the error message.
      This should avoid confusion when the key is an object with toString().
      E.g. undefined[{toString:()=>'a'}] doesn't print 'read property [object
      Object]' anymore, which was misleading since the property accessed would
      be 'a', but we can't evaluate the key without side effects.
      
      Bug: v8:11365
      Change-Id: If82d1adb42561d4851e2bd2ca297a1c71738aee8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960211Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Patrick Thier <pthier@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75250}
      24c626c1
  9. 21 May, 2021 1 commit
  10. 19 May, 2021 1 commit
  11. 10 May, 2021 1 commit
  12. 06 May, 2021 1 commit
  13. 30 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debugger] Don't attach source positions to implicit returns. · 379331b7
      Benedikt Meurer authored
      Previously we'd attach source positions to implicit returns that are
      generated when leaving an async function with a promise rejection. This
      was due to the use of `kNoSourcePosition` on the `end_position` in the
      `ReturnStatement` nodes as indicator to pick the return position from
      the function literal, instead of really not putting a source position on
      that specific `Return` bytecode.
      
      This CL adds a dedicated marker to `ReturnStatement` to express that the
      `BytecodeGenerator` should put the return position from the function
      literal there instead of overloading the meaning of `kNoSourcePosition`.
      
      Bug: chromium:901819, chromium:782461
      Fixed: chromium:1199919, chromium:1201706
      Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74301}
      379331b7
  14. 19 Mar, 2021 2 commits
  15. 02 Mar, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Don't put a source position on internal `Return`s. · 06359f74
      Benedikt Meurer authored
      Be explicit about source positions for `Return`s in the
      BytecodeGenerator, and only do self-healing explicitly in the
      `ReturnStatement` translation, where an end position of
      `kNoSourcePosition` is turned into the return position of the
      function literal.
      
      This allows us to reason more easily about which `Return`s actually
      receive a meaningful source position, and in particular it allows us
      to construct the internal `Return`s for `yield` and `yield*` with no
      source position attached to them. Previously they'd get the source
      position for the implicit (final) return attached to it, which confused
      the debugger and led to breakpoints being set in the completely wrong
      spot.
      
      Considering the simplified example
      
      ```
      function* foo(){
        var a = 1;
      }
      ```
      
      this would previously generate the following bytecode
      
      ```
              0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
              4 : Mov <closure>, r2
              7 : Mov <this>, r3
       13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
             14 : Star0
       13 E> 15 : SuspendGenerator r0, r0-r1, [0]
             20 : ResumeGenerator r0, r0-r1
             24 : Star2
             25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
             29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
             33 : Ldar r2
       13 E> 35 : Throw
             36 : Ldar r2
       30 S> 38 : Return    <=========================== internal Return
       27 S> 39 : LdaSmi [1]
             41 : Star1
             42 : LdaUndefined
       30 S> 43 : Return
      ```
      
      where everything between offset 4 and 42 corresponds to the implicit
      yield at the beginning of every generator function, in particular the
      code between 20 and 42 corresponds to that initial yields resumption
      logic. Notice how the internal Return at offset 38 gets assigned the
      source position of the function literal (the same as the implicit
      return at the end). This confuses the debugger quite a bit when trying
      to set a breakpoint on the closing brace, since it's going in bytecode
      order and will thus discover the `Return` at offset 38 first (matching
      the source position 30 it's currently looking for) and setting the
      breakpoint there. This `Return` bytecode however is only executed when
      the generator is resumed via `GeneratorPrototype.return()`, and it'll
      not hit when the developer uses the generator normally, which is not
      the desired behavior and extremely confusing (especially since stepping
      on the other hand works as expected).
      
      With this patch, we no longer slap a source position (and in particular
      not the function literal's return position) onto these internal
      `Return`s as you can see from the generated bytecode below:
      
      ```
             0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
             4 : Mov <closure>, r2
             7 : Mov <this>, r3
      13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
            14 : Star0
      13 E> 15 : SuspendGenerator r0, r0-r1, [0]
            20 : ResumeGenerator r0, r0-r1
            24 : Star2
            25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
            29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
            33 : Ldar r2
      13 E> 35 : Throw
            36 : Ldar r2
            38 : Return
      27 S> 39 : LdaSmi [1]
            41 : Star1
            42 : LdaUndefined
      30 S> 43 : Return
      ```
      
      This also allows us to remove the break position finding hack that was
      kept in BreakIterator::BreakIndexFromPosition() for generators and
      modules.
      
      Fixed: chromium:901819
      Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73119}
      06359f74
  16. 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
  17. 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
  18. 09 Feb, 2021 1 commit
  19. 29 Jan, 2021 1 commit
  20. 28 Jan, 2021 1 commit
    • Marja Hölttä's avatar
      Revert "Reland [super] Store home object in Context instead of JSFunction" · 12f8ac47
      Marja Hölttä authored
      This reverts commit f6450b97.
      
      Reason for revert: ClusterFuzz bugs
      
      Original change's description:
      > Reland [super] Store home object in Context instead of JSFunction
      >
      > 1) Computed property keys (esp functions in them) shouldn't be inside
      > the object literal scope.
      >
      > 2) I was using an imprecise "maybe uses super" and storing it to
      > preparse data. This won't fly, since it pollutes sister scopes and
      > leads to confusion wrt whether an object literal needs a home object
      > or not. Made it precise (mostly cancelling changes in the original CL).
      >
      > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
      > this_function (which made it used) -> inconsistent scopes between
      > parsing and preparsing.
      >
      > 4) MultipleEntryBlockContextScope was messing up the accumulator
      >
      > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
      >
      > This saves memory (the home object doesn't need to be stored for each
      > method, but only once per class) and hopefully makes the home object
      > a constant in the optimized code.
      >
      > Detailed documentation of the changes:
      > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
      >
      > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
      > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Marja Hölttä <marja@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72169}
      
      TBR=marja@chromium.org,leszeks@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9237
      Bug: chromium:1167918
      Bug: chromium:1167981
      Bug: chromium:1167988
      Bug: chromium:1168055
      Bug: chromium:1171195
      Bug: chromium:1171600
      Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72391}
      12f8ac47
  21. 26 Jan, 2021 1 commit
  22. 22 Jan, 2021 1 commit
  23. 19 Jan, 2021 2 commits
  24. 18 Jan, 2021 1 commit
  25. 17 Dec, 2020 1 commit
  26. 12 Nov, 2020 1 commit
  27. 29 Oct, 2020 1 commit
  28. 21 Oct, 2020 1 commit
  29. 19 Oct, 2020 1 commit
  30. 30 Sep, 2020 1 commit
  31. 25 Sep, 2020 1 commit
  32. 23 Sep, 2020 1 commit
  33. 11 Sep, 2020 1 commit
  34. 02 Sep, 2020 2 commits