1. 13 May, 2022 1 commit
  2. 25 Apr, 2022 1 commit
    • jameslahm's avatar
      Reland "[interpreter] Optimize strict equal boolean" · fce1047f
      jameslahm authored
      This is a reland of commit 62632c08.
      Reason for previous revert: Performance regressions crbug.com/1315724.
      The reland only optimizes strict equal boolean literal like "a===true"
      or "a===false", and we generate TestReferenceEqual rather than
      TestStrictEqual for the comparasion. And also add typed optimization
      for ReferenceEqual when all inputs are boolean with boolean constant.
      
      Original change's description:
      > [interpreter] Optimize strict equal boolean
      >
      > For strict equal boolean literal like "a===true"
      > or "a===false", we could generate TestReferenceEqual
      > rather than TestStrictEqual. And in `execution_result()->IsTest()`
      > case, we could directly emit JumpIfTrue/JumpIfFalse.
      >
      > E.g.
      > ```
      > a === true
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > ```
      > To:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestReferenceEqual
      > ```
      >
      > E.g.
      > ```
      > if (a === true)
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > JumpIfFalse
      > ```
      > To
      > ```
      > LdaGlobal
      > JumpIfTrue
      > Jump
      > ```
      >
      >
      > Bug: v8:6403
      > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: 王澳 <wangao.james@bytedance.com>
      > Cr-Commit-Position: refs/heads/main@{#79935}
      
      Bug: v8:6403
      Change-Id: I2ae3ab57dce85313af200fa522e3632af5c3a554
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592039Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#80141}
      fce1047f
  3. 19 Apr, 2022 1 commit
    • Jakob Linke's avatar
      Revert "[interpreter] Optimize strict equal boolean" · 3b772a23
      Jakob Linke authored
      This reverts commit 62632c08.
      
      Reason for revert: Performance regressions crbug.com/1315724
      
      Original change's description:
      > [interpreter] Optimize strict equal boolean
      >
      > For strict equal boolean literal like "a===true"
      > or "a===false", we could generate TestReferenceEqual
      > rather than TestStrictEqual. And in `execution_result()->IsTest()`
      > case, we could directly emit JumpIfTrue/JumpIfFalse.
      >
      > E.g.
      > ```
      > a === true
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > ```
      > To:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestReferenceEqual
      > ```
      >
      > E.g.
      > ```
      > if (a === true)
      > ```
      > Generated Bytecode From:
      > ```
      > LdaGlobal
      > Star1
      > LdaTrue
      > TestEqualStrict
      > JumpIfFalse
      > ```
      > To
      > ```
      > LdaGlobal
      > JumpIfTrue
      > Jump
      > ```
      >
      >
      > Bug: v8:6403
      > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: 王澳 <wangao.james@bytedance.com>
      > Cr-Commit-Position: refs/heads/main@{#79935}
      
      Bug: v8:6403, chromium:1315724
      Change-Id: I65c520590093724e838f738c795d229687efb9de
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592752Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Jakob Linke <jgruber@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/main@{#80010}
      3b772a23
  4. 12 Apr, 2022 1 commit
    • jameslahm's avatar
      [interpreter] Optimize strict equal boolean · 62632c08
      jameslahm authored
      For strict equal boolean literal like "a===true"
      or "a===false", we could generate TestReferenceEqual
      rather than TestStrictEqual. And in `execution_result()->IsTest()`
      case, we could directly emit JumpIfTrue/JumpIfFalse.
      
      E.g.
      ```
      a === true
      ```
      Generated Bytecode From:
      ```
      LdaGlobal
      Star1
      LdaTrue
      TestEqualStrict
      ```
      To:
      ```
      LdaGlobal
      Star1
      LdaTrue
      TestReferenceEqual
      ```
      
      E.g.
      ```
      if (a === true)
      ```
      Generated Bytecode From:
      ```
      LdaGlobal
      Star1
      LdaTrue
      TestEqualStrict
      JumpIfFalse
      ```
      To
      ```
      LdaGlobal
      JumpIfTrue
      Jump
      ```
      
      
      Bug: v8:6403
      Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: 王澳 <wangao.james@bytedance.com>
      Cr-Commit-Position: refs/heads/main@{#79935}
      62632c08
  5. 23 Mar, 2022 1 commit
  6. 10 Mar, 2022 1 commit
  7. 03 Mar, 2022 1 commit
  8. 10 Feb, 2022 1 commit
  9. 15 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Post compile tasks from ignition instead of the parser · 6b2fa4c1
      Leszek Swirski authored
      Posting compile tasks from the parser has several issues:
      
        1. We don't know how many functions there will be total, so we can't
           yet allocate shared_function_infos array on the Script
        2. Without this array, inner function compiles can't look up their own
           inner functions during bytecode finalization, so we can't run that
           finalization before script parse completes
        3. Scope analysis can't have run yet, so we can only post top-level
           function tasks and if we allocate SharedFunctionInfos early they
           are forced into a bit of a limbo state without an outer ScopeInfo.
      
      Instead, we can post compile tasks during bytecode generation. Then, the
      script parse is guaranteed to have completed, so we'll have a
      shared_function_infos array and we will have allocated ScopeInfos
      already. This also opens the door for posting tasks for compiling more
      inner functions than just top-level, as well as generating better code
      for functions/methods that reference same-script top-level
      let/const/class.
      
      Bug: chromium:1267680
      Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77894}
      6b2fa4c1
  10. 04 Nov, 2021 1 commit
  11. 05 Jul, 2021 1 commit
  12. 23 Jun, 2021 1 commit
  13. 21 May, 2021 1 commit
  14. 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
  15. 26 Apr, 2021 1 commit
  16. 19 Mar, 2021 2 commits
  17. 18 Feb, 2021 1 commit
  18. 29 Jan, 2021 1 commit
  19. 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
  20. 19 Jan, 2021 2 commits
  21. 18 Jan, 2021 1 commit
  22. 07 Jan, 2021 1 commit
  23. 03 Nov, 2020 1 commit
  24. 02 Nov, 2020 1 commit
  25. 22 Oct, 2020 1 commit
  26. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored
      This patch introduces a new LocalIsolate and LocalFactory, which use
      LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
      us to remove those classes, as well as the related OffThreadSpace,
      OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
      OffThreadLogger becomes LocalLogger.
      
      LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
      us to additionally remove the concept of "Finish" and "Publish" that the
      OffThreadIsolate had, and allows us to internalize strings directly with
      the newly-concurrent string table (where the implementation can now move
      to FactoryBase).
      
      This patch also removes the off-thread support from the deserializer
      entirely, as well as removing the LocalIsolateWrapper which allowed
      run-time distinction between Isolate and OffThreadIsolate. LocalHeap
      doesn't support the reservation model used by the deserializer, and we
      will likely move the deserializer to use LocalIsolate unconditionally
      once we figure out the details of how to do this.
      
      Bug: chromium:1011762
      
      Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  27. 10 Aug, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [ast] Store correct source position on ThisExpression · 8a9e3f64
      Sathya Gunasekaran authored
      Previously, all ThisExpression's had kNoSourcePositions leading to
      incorrect error messages like this:
      
        ➜ d8 -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: undefined is not a function
        function t() { for (const x of this) {} } t();
                  ^
        TypeError: undefined is not a function
            at t (unnamed:1:11)
            at unnamed:1:43
      
      
      This patch allows creation of a ThisExpression with a source position,
      leading to a better error message:
      
        ➜ d8  -e "function t() { for (const x of this) {} } t();"
        unnamed:1: TypeError: this is not iterable
        function t() { for (const x of this) {} } t();
                                       ^
        TypeError: this is not iterable
            at t (unnamed:1:32)
            at unnamed:1:43
      
      
      This patch does not remove the existing cached version of
      ThisExpression and instead creates a new one when required.
      
      Bug: v8:6513
      Change-Id: Idee4fe8946a9b821d06ff4a5e7eaefe54874ec59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345226Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69300}
      8a9e3f64
  28. 06 Aug, 2020 1 commit
    • Bill Budge's avatar
      Reland "[torque] Port some constructor builtins to Torque." · 83e4c8b1
      Bill Budge authored
      This is a reland of ce249dbb
      
      As it's unchanged,
      TBR=leszeks@chromium.org,tebbi@chromium.org
      
      Original change's description:
      > [torque] Port some constructor builtins to Torque.
      >
      > - FastNewFunctionContextEval
      > - FastNewFunctionContextFunction
      > - CreateEmptyLiteralObject
      > - CreateRegExpLiteral
      > - CreateEmptyArrayLiteral
      > - CreateShallowArrayLiteral
      > - CreateShallowObjectLiteral
      > - NumberConstructor
      > - ObjectConstructor
      > - GenericLazyDeoptContinuation
      >
      > Bug: v8:9891
      >
      > Change-Id: Idd4bf035d8dbeec03b9ef727e1bfb80eab4bc43c
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2311411
      > Commit-Queue: Bill Budge <bbudge@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#69082}
      
      Bug: v8:9891
      Change-Id: I566d4167c02488ef6a9a1c73015af5e2f484a31d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330382
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69281}
      83e4c8b1
  29. 30 Jul, 2020 1 commit
  30. 27 Jul, 2020 2 commits
  31. 13 Jul, 2020 1 commit
  32. 10 Jul, 2020 1 commit
  33. 08 Jul, 2020 1 commit
  34. 25 May, 2020 1 commit
  35. 08 May, 2020 1 commit
  36. 06 May, 2020 1 commit
    • Leszek Swirski's avatar
      [parser] Move Compiler::Analyze into Parser · 65d738d4
      Leszek Swirski authored
      Move rewriting, scope analysis, and internalization, to be unconditional
      operations done after parsing rather than a separate compile phase. This
      removes some of the complexity about rememberering when to call
      Compiler::Analyze, and makes these paths a bit more uniform.
      
      Also, forbid allocating any more AST strings after AstValueFactory
      internalization, by nulling out the Zone. Add an InternalizePartial
      method which doesn't null out the zone for those cases where we do want
      to be able to allocate after internalizing (e.g. internalization before
      scope analysis).
      
      Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67608}
      65d738d4
  37. 21 Apr, 2020 1 commit