1. 01 Aug, 2022 1 commit
    • Nico Weber's avatar
      Make bitfields only as wide as necessary for enums · d15d49b0
      Nico Weber authored
      clang now complains when a BitField for an enum is too wide.
      We could suppress this, but it seems kind of useful from an
      uninformed distance, so I made a few bitfields smaller instead.
      
      (For AddressingMode, since its size is target-dependent, I added
      an explicit underlying type to the enum instead, which suppresses
      the diag on a per-enum basis.)
      
      This is without any understanding of the code I'm touching.
      Especially the change in v8-internal.h feels a bit risky to me.
      
      Bug: chromium:1348574
      Change-Id: I73395de593045036b72dadf4e3147b5f7e13c958
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794708
      Commit-Queue: Nico Weber <thakis@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Auto-Submit: Nico Weber <thakis@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#82109}
      d15d49b0
  2. 05 Jul, 2022 3 commits
  3. 20 Jun, 2022 1 commit
  4. 13 May, 2022 1 commit
  5. 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
  6. 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
  7. 15 Apr, 2022 1 commit
  8. 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
  9. 23 Mar, 2022 2 commits
  10. 10 Mar, 2022 1 commit
  11. 07 Mar, 2022 1 commit
  12. 03 Mar, 2022 1 commit
  13. 21 Feb, 2022 1 commit
  14. 16 Feb, 2022 1 commit
  15. 10 Feb, 2022 1 commit
  16. 07 Feb, 2022 2 commits
  17. 31 Jan, 2022 1 commit
  18. 27 Jan, 2022 1 commit
  19. 26 Jan, 2022 1 commit
  20. 24 Jan, 2022 1 commit
    • Joyee Cheung's avatar
      Reland "[class] implement reparsing of class instance member initializers" · 0e07eb53
      Joyee Cheung authored
      This is a reland of 91f08378
      
      When the class scope does not need a context, the deserialized
      outer scope of the initializer scope would not be the class scope,
      and we should not and do not need to use it to fix up the allocation
      information of the context-allocated variables. The original patch
      did not consider this case and resulted in a regression when we
      tried to reparse the initializer function to look for destructuring
      assignment errors. This fixes the regression by not deserializing
      the class scope that's going to be reparsed, and using the positions
      of the scopes to tell whether the scope info matches the reparsed
      scope and can be used to fix up the allocation info.
      
      Original change's description:
      > [class] implement reparsing of class instance member initializers
      >
      > Previously, since the source code for the synthetic class instance
      > member initializer function was recorded as the span from the first
      > initializer to the last initializer, there was no way to reparse the
      > class and recompile the initializer function. It was working for
      > most use cases because the code for the initializer function was
      > generated eagarly and it was usually alive as long as the class was
      > alive, so the initializer wouldn't normally be lazily parsed. This
      > didn't work, however, when the class was snapshotted with
      > v8::SnapshotCreator::FunctionCodeHandling::kClear,
      > becuase then we needed to recompile the initializer when the class
      > was instantiated. This patch implements the reparsing so that
      > these classes can work with FunctionCodeHandling::kClear.
      >
      > This patch refactors ParserBase::ParseClassLiteral() so that we can
      > reuse it for both parsing the class body normally and reparsing it
      > to collect initializers. When reparsing the synthetic initializer
      > function, we rewind the scanner to the beginning of the class, and
      > parse the class body to collect the initializers. During the
      > reparsing, field initializers are parsed with the full parser while
      > methods of the class are pre-parsed.
      >
      > A few notable changes:
      >
      > - Extended the source range of the initializer function to cover the
      >   entire class so that we can rewind the scanner to parse the class
      >   body to collect initializers (previously, it starts from the first
      >   field initializer and ends at the last initializer). This resulted
      >   some expectation changes in the debugger tests, though the
      >   initializers remain debuggable.
      > - A temporary ClassScope is created during reparsing. After the class
      >   is reparsed, we use the information from the ScopeInfo to update
      >   the allocated indices of the variables in the ClassScope.
      >
      > Bug: v8:10704
      > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#78299}
      
      Bug: chromium:1278086, chromium:1278085, v8:10704
      Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78745}
      0e07eb53
  21. 19 Jan, 2022 1 commit
  22. 17 Jan, 2022 1 commit
    • Victor Gomes's avatar
      Reland "[runtime] Adds LocalNameIterator" · 4ebc9b7b
      Victor Gomes authored
      This is a reland of f605d778
      
      Adds a GC safe (using handles) and unsafe versions of the iterator.
      
      V8HeapExplorer needs an unsafe one, since it does not allow the
      creation of handles.
      
      Original change's description:
      > [runtime] Adds LocalNameIterator
      >
      > ScopeInfo will contain either inlined (array) local names or
      > a hash table (names => index) containing the local names.
      >
      > We abstract iteration with LocalNameIterator and remove
      > ContextLocalName since accessing a local name by index in
      > the hash table would be expensive.
      >
      > This CL only implements the iterator for the array.
      >
      > Bug: v8:12315
      > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78623}
      
      Bug: v8:12315
      Change-Id: I6288a08b9c342cd3a9cabcb621c40bb44c08c9c4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394706Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78653}
      4ebc9b7b
  23. 14 Jan, 2022 3 commits
    • Leszek Swirski's avatar
      Revert "[runtime] Adds LocalNameIterator" · 1e42a27f
      Leszek Swirski authored
      This reverts commit f605d778.
      
      Reason for revert: Segfaults: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36908/overview
      
      Original change's description:
      > [runtime] Adds LocalNameIterator
      >
      > ScopeInfo will contain either inlined (array) local names or
      > a hash table (names => index) containing the local names.
      >
      > We abstract iteration with LocalNameIterator and remove
      > ContextLocalName since accessing a local name by index in
      > the hash table would be expensive.
      >
      > This CL only implements the iterator for the array.
      >
      > Bug: v8:12315
      > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#78623}
      
      Bug: v8:12315
      Change-Id: Ibabe231f4357a3dd02d24b89847d579b83867a1a
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386385
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78625}
      1e42a27f
    • Victor Gomes's avatar
      [runtime] Adds LocalNameIterator · f605d778
      Victor Gomes authored
      ScopeInfo will contain either inlined (array) local names or
      a hash table (names => index) containing the local names.
      
      We abstract iteration with LocalNameIterator and remove
      ContextLocalName since accessing a local name by index in
      the hash table would be expensive.
      
      This CL only implements the iterator for the array.
      
      Bug: v8:12315
      Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78623}
      f605d778
    • Victor Gomes's avatar
      [runtime] Update SavedClassVariable in ScopeInfo · 2fdc823a
      Victor Gomes authored
      ScopeInfo will contain either inlined (array) local names or
      a hash table (names => index) containing the local names.
      
      If we have the local names inlined, we should save the class
      variable context slot index.
      
      If we have a hash table instead, we should save the class
      variable offset in the internal hash table storage.
      
      Bug: v8:12315
      Change-Id: Ifd9ae4f285d11fc034e8560c8558038b38a474fb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386599Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78621}
      2fdc823a
  24. 13 Jan, 2022 1 commit
  25. 13 Dec, 2021 1 commit
  26. 10 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [parser] Split AstRawString and Parser zones · ef0b2aab
      Leszek Swirski authored
      This allows us to reuse AstValueFactory's string table across multiple
      parsers, while still releasing memory after each individual parse.
      
      This is mild overkill for all the single parses that don't reuse
      AstValueFactories, but there at least the AstRawStrings now end up
      grouped together in memory, so that might have mild cache benefits.
      
      Change-Id: I0b378760b601fa4ec6559a0dca5d7ed6f895e992
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322764Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78338}
      ef0b2aab
  27. 09 Dec, 2021 1 commit
    • Joyee Cheung's avatar
      Revert "[class] implement reparsing of class instance member initializers" · f668e9f7
      Joyee Cheung authored
      This reverts commit 91f08378.
      
      Reason for revert: It's a fairly big change, and the clusterfuzz
      found some bugs. Will reland with the fix after M98 branch point.
      
      Original change's description:
      > [class] implement reparsing of class instance member initializers
      >
      > Previously, since the source code for the synthetic class instance
      > member initializer function was recorded as the span from the first
      > initializer to the last initializer, there was no way to reparse the
      > class and recompile the initializer function. It was working for
      > most use cases because the code for the initializer function was
      > generated eagarly and it was usually alive as long as the class was
      > alive, so the initializer wouldn't normally be lazily parsed. This
      > didn't work, however, when the class was snapshotted with
      > v8::SnapshotCreator::FunctionCodeHandling::kClear,
      > becuase then we needed to recompile the initializer when the class
      > was instantiated. This patch implements the reparsing so that
      > these classes can work with FunctionCodeHandling::kClear.
      >
      > This patch refactors ParserBase::ParseClassLiteral() so that we can
      > reuse it for both parsing the class body normally and reparsing it
      > to collect initializers. When reparsing the synthetic initializer
      > function, we rewind the scanner to the beginning of the class, and
      > parse the class body to collect the initializers. During the
      > reparsing, field initializers are parsed with the full parser while
      > methods of the class are pre-parsed.
      >
      > A few notable changes:
      >
      > - Extended the source range of the initializer function to cover the
      >   entire class so that we can rewind the scanner to parse the class
      >   body to collect initializers (previously, it starts from the first
      >   field initializer and ends at the last initializer). This resulted
      >   some expectation changes in the debugger tests, though the
      >   initializers remain debuggable.
      > - A temporary ClassScope is created during reparsing. After the class
      >   is reparsed, we use the information from the ScopeInfo to update
      >   the allocated indices of the variables in the ClassScope.
      >
      > Bug: v8:10704
      > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Joyee Cheung <joyee@igalia.com>
      > Cr-Commit-Position: refs/heads/main@{#78299}
      
      Bug: v8:10704
      Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328
      Auto-Submit: Joyee Cheung <joyee@igalia.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78315}
      f668e9f7
  28. 08 Dec, 2021 2 commits
    • Joyee Cheung's avatar
      [class] implement reparsing of class instance member initializers · 91f08378
      Joyee Cheung authored
      Previously, since the source code for the synthetic class instance
      member initializer function was recorded as the span from the first
      initializer to the last initializer, there was no way to reparse the
      class and recompile the initializer function. It was working for
      most use cases because the code for the initializer function was
      generated eagarly and it was usually alive as long as the class was
      alive, so the initializer wouldn't normally be lazily parsed. This
      didn't work, however, when the class was snapshotted with
      v8::SnapshotCreator::FunctionCodeHandling::kClear,
      becuase then we needed to recompile the initializer when the class
      was instantiated. This patch implements the reparsing so that
      these classes can work with FunctionCodeHandling::kClear.
      
      This patch refactors ParserBase::ParseClassLiteral() so that we can
      reuse it for both parsing the class body normally and reparsing it
      to collect initializers. When reparsing the synthetic initializer
      function, we rewind the scanner to the beginning of the class, and
      parse the class body to collect the initializers. During the
      reparsing, field initializers are parsed with the full parser while
      methods of the class are pre-parsed.
      
      A few notable changes:
      
      - Extended the source range of the initializer function to cover the
        entire class so that we can rewind the scanner to parse the class
        body to collect initializers (previously, it starts from the first
        field initializer and ends at the last initializer). This resulted
        some expectation changes in the debugger tests, though the
        initializers remain debuggable.
      - A temporary ClassScope is created during reparsing. After the class
        is reparsed, we use the information from the ScopeInfo to update
        the allocated indices of the variables in the ClassScope.
      
      Bug: v8:10704
      Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Cr-Commit-Position: refs/heads/main@{#78299}
      91f08378
    • Leszek Swirski's avatar
      [compiler] Introduce ReusableUnoptimizedCompileState · b3e1eb0c
      Leszek Swirski authored
      Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
      which stores a couple of pointers and most importantly the Zone and
      AstValueFactory of the parse. This allows the Zone and AstValueFactory
      to be reused across multiple parses, rather than re-initialising
      per-Parse.
      
      With this, we can amend the LazyCompileDispatcher to initialise one
      LocalIsolate, Zone and AstValueFactory per background thread loop,
      rather than one per compile task, which allows us to reduce per-task
      costs and re-use the AstValueFactory's string table and previous String
      internalizations.
      
      Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78289}
      b3e1eb0c
  29. 01 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Enqueue tasks for non-eager inner funcs · 5ab1ec1e
      Leszek Swirski authored
      Add suppose for compiling non-eager, non-top-level inner functions in
      parallel, using the compiler dispatcher. This behaviour can be enabled
      with --parallel-compile-tasks-for-lazy.
      
      There are a couple of consequences:
      
        * To support this we need support for off-thread ScopeInfo
          deserialization, so this adds that too.
        * The previous --parallel-compile-tasks flag is renamed to the more
          descriptive --parallel-compile-tasks-for-eager-toplevel.
        * Both parallel-compile-tasks flags are moved onto
          UnoptimizedCompileFlags so that they can be enabled/disabled on a
          per-compile basis (e.g. enabled for streaming, disabled for
          re-parsing).
        * asm.js compilations can now happen without an active Context (in
          the compiler dispatcher's idle finalization) so we can't get a
          ContextId for metric reporting; we'd need to somehow fix this if we
          wanted asm.js UKM but for now it's probably fine.
        * Took the opportunity to clean up some of the "can preparse" logic in
          the parser.
      
      Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78183}
      5ab1ec1e
  30. 16 Nov, 2021 1 commit
  31. 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
  32. 04 Nov, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move to full SFI keying · 14097e62
      Leszek Swirski authored
      Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
      the canonical id for these jobs.
      
      This has several consequences:
      
        * We no longer split enqueing a job and registering a SFI with that
          job. We did this previously because we could not allocate SFIs in
          the Parser -- now with LocalHeap we can, so we do.
        * We remove the separate Job vector, and make the SFI IdentityMap
          hold pointers to Jobs directly. This requires a small amount of
          extra care to deallocate Jobs when removing them from the map,
          but it means not having to allocate new global handles for jobs.
        * The SFI is passed into the BackgroundCompileTask instead of the
          script, so our task finalization doesn't need the SFI anymore.
        * We no longer need to iterate ParallelTasks after compiling (to
          register SFIs), so we can get rid of ParallelTasks entirely and
          access the dispatcher directly from the parser.
      
      There are a few drive-bys since we're touching this code:
      
        * Jobs are move to have a "state" variable rather than a collection
          of bools, for stricter DCHECKing.
        * There's no longer a set of "currently running" jobs, since this
          was only used to check if a job is running, we can instead inspect
          the job's state directly.
        * s/LazyCompilerDispatcher/LazyCompileDispatcher/g
      
      Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77712}
      14097e62
    • Leszek Swirski's avatar
      [compiler] Simplify SFI flag initialisation · 71bffcce
      Leszek Swirski authored
      Some post-compile flag setting was unnecessary, since those flags
      originally came from the SFI they were being set on.
      
      Also, DontOptimizeReason was never actually set, so we can remove it
      entirely.
      
      Change-Id: Ic07821fc20ba4e16a2bd8b9e8ac8c1b266aa4067
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260510
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77702}
      71bffcce