1. 14 Oct, 2020 2 commits
  2. 05 Oct, 2020 1 commit
  3. 01 Oct, 2020 1 commit
    • Dan Elphick's avatar
      [CSA] Tnodify CodeAssembler::Parameter · 74a9b9c4
      Dan Elphick authored
      CodeAssembler::Parameter now takes a Type template parameter and
      performs a checked cast to it. There is also UncheckedParameter which
      returns a TNode but doesn't check the cast. The original Parameter
      method is still there as UntypedParameter.
      
      Parameter<T>(x) in many cases replaces CAST(Parameter(x)), where the
      cast is performed inside Parameter. Since Parameter is not a macro,
      this means it cannot see the original expression or its file name and
      line number. So the error messages are vaguely useful, Parameter<T>()
      takes a SourceLocation parameter which with a default value of
      SourceLocation::Current(), which at least gives us the file name and
      line number for the error message.
      
      Bug: v8:6949, v8:10933
      Change-Id: I27157bec7dc7462210c1eb9c430c0180217d25c1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435106Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70264}
      74a9b9c4
  4. 25 Sep, 2020 4 commits
  5. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  6. 08 Sep, 2020 3 commits
  7. 02 Sep, 2020 1 commit
  8. 28 Aug, 2020 1 commit
  9. 21 Aug, 2020 1 commit
  10. 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
  11. 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
  12. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  13. 29 Jul, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Update interrupt budget from NCI code · 980e224a
      Jakob Gruber authored
      This is the first step towards implementing a tier-up mechanism from
      NCI code to TF. We will follow the existing Ignition-to-Turbofan
      mechanics, which are, roughly:
      
      1. Track a bytecode interrupt budget.
      2. When exhausted, call the runtime profiler, which increments
         profiler ticks for the top frame's function.
      3. When a function should tier up, it is marked as such using the
         FeedbackVector::optimized_code_weak_or_smi slot / the
         OptimizationMarker mechanism.
      4. The InterpreterEntryTrampoline checks this slot and calls into
         runtime to compile if needed.
      5. The finished code is also placed into this slot, as well as
         installed on the JSFunction.
      6. Again, the IET checks the slot and tail-calls the code object if it
         exists.
      
      This CL implements step 1 for NCI code by inserting the new simplified
      UpdateInterruptBudget operator at the same spots (and using the same
      offsets) as Ignition. When the budget is exhausted, we call a runtime
      function that currently does nothing and will be implemented in the
      next CL.
      
      Bug: v8:8888
      Change-Id: I98c0f8d96f32d515218dc2a76f961d44fe281c86
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2312778
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69124}
      980e224a
  14. 27 Jul, 2020 2 commits
  15. 24 Jul, 2020 2 commits
  16. 22 Jul, 2020 1 commit
    • Seth Brenith's avatar
      Profile-guided optimization of builtins · 922983df
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
      
      V8 can already collect data about how many times each basic block in the
      builtins is run. This change enables using that data for profile-guided
      optimization. New comments in BUILD.gn describe how to use this feature.
      
      A few implementation details worth mentioning, which aren't covered in
      the design doc:
      
      - BasicBlockProfilerData currently contains an array of RPO numbers.
        However, this array is always just [0, 1, 2, 3, ...], so this change
        removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
        ensures that the removal is valid.
      
      - RPO numbers, while useful for printing data that matches with the
        stringified schedule, are not useful for matching profiling data with
        blocks that haven't been scheduled yet. This change adds a new array
        of block IDs in BasicBlockProfilerData, so that block counters can be
        used for PGO.
      
      - Basic block counters need to be written to a file so that they can be
        provided to a subsequent run of mksnapshot, but the design doc doesn't
        specify the transfer format or what file is used. In this change, I
        propose using the existing v8.log file for that purpose. Block count
        records look like this:
      
        block,TestLessThanHandler,37,29405
      
        This line indicates that block ID 37 in TestLessThanHandler was run
        29405 times. If multiple lines refer to the same block, the reader
        adds them all together. I like this format because it's easy to use:
        - V8 already has robust logic for creating the log file, naming it to
          avoid conflicts in multi-process situations, etc.
        - Line order doesn't matter, and interleaved writes from various
          logging sources are fine, given that V8 writes each line atomically.
        - Combining multiple sources of profiling data is as simple as
          concatenating their v8.log files together.
      
      - It is a good idea to avoid making any changes based on profiling data
        if the function being compiled doesn't match the one that was
        profiled, since it is common to use profiling data downloaded from a
        central lab which is updated only periodically. To check whether a
        function matches, I propose using a hash of the Graph state right
        before scheduling. This might be stricter than necessary, as some
        changes to the function might be small enough that the profile data is
        still relevant, but I'd rather err on the side of not making incorrect
        changes. This hash is also written to the v8.log file, in a line that
        looks like this:
      
        builtin_hash,LdaZeroHandler,3387822046
      
      Bug: v8:10470
      Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69008}
      922983df
  17. 15 Jul, 2020 1 commit
  18. 13 Jul, 2020 1 commit
  19. 10 Jul, 2020 1 commit
  20. 08 Jul, 2020 1 commit
  21. 07 Jul, 2020 1 commit
  22. 17 Jun, 2020 1 commit
  23. 03 Jun, 2020 1 commit
    • Jakob Gruber's avatar
      Include standard heap object header when debug-printing String objects · 86fee30e
      Jakob Gruber authored
      This brings %DebugPrint(string) closer to %DebugPrint(object) by also
      including the pointer, object kind, and RO/old space. Especially the
      pointer can be useful while debugging.
      
      One could consider going even further end printing full details of
      the string object, e.g. first and second pointers for cons strings.
      
      Before:
      
       $ out/debug/d8 --allow-natives-syntax -e '%DebugPrint("abc");'
       DebugPrint: #abc
       0x263f080402cd: [Map] in ReadOnlySpace
       [...]
      
      After:
      
       $ out/debug/d8 --allow-natives-syntax -e '%DebugPrint("abc");'
       DebugPrint: 0xa830824ffe1: [String] in OldSpace: #abc
       0xa83080402cd: [Map] in ReadOnlySpace
       [...]
      
      Drive-by: Document string printing functions.
      Drive-by: Use PrintUC16 in spots that don't want a full debug print.
      
      Bug: v8:10581
      Change-Id: Ided59047b9c3edc1830ce7721376dddfd24fad1d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2228509Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68136}
      86fee30e
  24. 02 Jun, 2020 1 commit
  25. 27 May, 2020 1 commit
  26. 25 May, 2020 2 commits
  27. 12 May, 2020 1 commit
  28. 11 May, 2020 1 commit
  29. 07 May, 2020 1 commit
  30. 06 May, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Unify compiler.cc finalization logic · 58b12f63
      Leszek Swirski authored
      This patch unfies the finalization logic between the various unoptimized
      compilation paths in compiler.cc, taking the various post-processings and
      fixups needed for off-thread finalization and performing them in the same
      order for the other finalizations.
      
      It also unifies the general compilation path between streaming script
      compilation, main-thread script compilation, and main-thread lazy
      compilation, making the main-thread paths both use an iterative execution
      and finalization, and making all three use the same job helper methods
      and overall finalization helper.
      
      Bug: chromium:1011762
      Change-Id: Ibe56f6d2f75a2deffbe9e0b600ded8a02293b722
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172790
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67609}
      58b12f63