1. 17 Jun, 2021 1 commit
  2. 16 Jun, 2021 1 commit
  3. 15 Jun, 2021 1 commit
  4. 09 Jun, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] RawFastPropertyAt without serialization · 9bfd401e
      Jakob Gruber authored
      This is a step towards making JSObjectRef non-serialized.
      
      Change JSObjectRef::RawFastPropertyAt to use a direct load with
      relaxed semantics. Special handling of `uninitialized` sentinel values
      is moved to the only use-site.
      
      A new lock `boilerplate_migration_access` protects against concurrent
      boilerplate migrations while we are iterating over properties.
      
      Bug: v8:7790
      Change-Id: Ic9de54ca16c1f3364d497a77058cfa33d48dd4a4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2928184
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75033}
      9bfd401e
  5. 07 Jun, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Remove use of serialized JSObjectRef::elements · 8769666e
      Jakob Gruber authored
      .. and replace them by elements read directly from the heap object.
      
      With this change, consistency between `map` and `elements` is
      no longer guaranteed. Users were updated, when necessary, to deal
      with this, e.g. by being more careful not to read out of bounds,
      by inserting new `actual_elements == elements_constant` runtime
      checks, or through a new compilation dependency that verifies
      unchanged elements at finalization time.
      
      Drive-by: inline GetElementsKind into callsites.
      
      Bug: v8:7790
      Change-Id: Ifba78182e185ff0d4e954e3be52f0eb24328c853
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2909655Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74977}
      8769666e
  6. 26 May, 2021 1 commit
  7. 18 May, 2021 1 commit
  8. 17 May, 2021 1 commit
  9. 05 May, 2021 3 commits
  10. 29 Apr, 2021 1 commit
  11. 27 Apr, 2021 1 commit
  12. 13 Apr, 2021 1 commit
    • Maya Lekova's avatar
      [turbofan] Move large array allocation bailout earlier · 930f2654
      Maya Lekova authored
      The CanAllocateArray used to be executed during JSCreateLowering,
      leading to bailouts when large arrays are passed as arguments to
      an async function or a bound function. This meant that
      JSCreateAsyncFunctionObject or JSCreateBoundFunction will reach
      JSGenericLowering, where they are not lowered. This CL moves
      the checks earlier in the pipeline during JSNativeContextSpecialization
      and JSCallReducer respectively, so that those operators are not
      created at all in such cases and we bail out to the runtime instead.
      
      Bug: v8:11564
      Change-Id: I232ce7d9378730ae0cc8690e52fde840a484e069
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2807609
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73928}
      930f2654
  13. 12 Apr, 2021 1 commit
    • Wenyu Zhao's avatar
      Allowing map word to be used for other state in GC header. · 5e0b94c4
      Wenyu Zhao authored
      This CL adds features to pack/unpack map words.
      
      Currently V8 cannot store extra metadata in object headers -- because V8
      objects do not have a proper header, but only a map pointer at the start
      of the object. To store per-object metadata like marking data, a side
      table is required as the per-object metadata storage.
      
      This CL enables V8 to use higher unused bits in a 64-bit map word as
      per-object metadata storage. Map pointer stores come with an extra step
      to encode the metadata into the pointer (we call it "map packing").
      Map pointer loads will also remove the metadata bits as well (we call it
      "map packing").
      
      Since the map word is no longer a valid pointer after packing, we also
      change the tag of the packed map word to make it looks like a Smi. This
      helps various GC and barrier code to correctly skip them instead of
      blindly dereferencing this invalid pointer.
      
      A ninja flag `v8_enable_map_packing` is provided to turn this
      map-packing feature on and off. It is disabled by default.
      
      * Only works on x64 platform, with `v8_enable_pointer_compression`
        set to `false`
      
      Bug: v8:11624
      Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73915}
      5e0b94c4
  14. 22 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Direct heap reads for JSArrayRef" · 2e844377
      Jakob Gruber authored
      This is a reland of 76a2ab06
      
      Changes since the original CL:
      - Handle unserialized elements (optional result in getter).
      - Merge should_access_heap and --turbo-direct-heap-access paths.
      - Slightly update the serialized path in GetOwnCowElement.
      - Fix the cctest, add a regression test.
      
      Atomic JSObject::elements/JSArray::length setters are addressed
      in this CL: crrev.com/c/2704076.
      
      Original change's description:
      > [compiler] Direct heap reads for JSArrayRef
      >
      > There are two aspects to the non-JSObject parts of JSArrayRef:
      >
      > - JSArrayRef::length. Relevant only in two spots, 1. when reading
      > (immutable) array boilerplates and 2. for GetOwnCowElement.
      >
      > - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      > store. Relies on the invariant that cow backing stores are immutable.
      >
      > This CL renames the length accessor to length_unsafe to make the
      > danger explicit at callsites.
      >
      > For GetOwnCowElement the refactor is slightly larger, since we now
      > need to read into the backing store while keeping full control of
      > object reads (e.g. JSArray::length and JSArray::elements_kind). We
      > make all reads explicit at the call site by requiring that elements,
      > elements kind, and length are passed in as arguments to
      > GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      > is *not* guaranteed due to concurrency. At runtime, consistency *is*
      > guaranteed through the reference-equality check on the elements seen
      > during compilation. The actual elements read is implemented in
      > ConcurrentLookupIterator::GetOwnCowElement.
      >
      > Bug: v8:7790
      > Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72834}
      
      Bug: v8:7790
      Change-Id: I7577ad554992cafff81099a28c34f27db9bd8042
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2710431
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72904}
      2e844377
  15. 19 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Direct heap reads for JSArrayRef" · 3cfe4fe0
      Georg Neis authored
      This reverts commit 76a2ab06.
      
      Reason for revert: A few issues, e.g.
      https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8854931126653780144/+/u/Check__flakes_/ArrayWithCowElements
      
      Original change's description:
      > [compiler] Direct heap reads for JSArrayRef
      >
      > There are two aspects to the non-JSObject parts of JSArrayRef:
      >
      > - JSArrayRef::length. Relevant only in two spots, 1. when reading
      > (immutable) array boilerplates and 2. for GetOwnCowElement.
      >
      > - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      > store. Relies on the invariant that cow backing stores are immutable.
      >
      > This CL renames the length accessor to length_unsafe to make the
      > danger explicit at callsites.
      >
      > For GetOwnCowElement the refactor is slightly larger, since we now
      > need to read into the backing store while keeping full control of
      > object reads (e.g. JSArray::length and JSArray::elements_kind). We
      > make all reads explicit at the call site by requiring that elements,
      > elements kind, and length are passed in as arguments to
      > GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      > is *not* guaranteed due to concurrency. At runtime, consistency *is*
      > guaranteed through the reference-equality check on the elements seen
      > during compilation. The actual elements read is implemented in
      > ConcurrentLookupIterator::GetOwnCowElement.
      >
      > Bug: v8:7790
      > Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72834}
      
      Bug: v8:7790, chromium:1180012
      Change-Id: I50e72380c544b2b78e1e3dc87a8249281b710912
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704666
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72860}
      3cfe4fe0
  16. 18 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Direct heap reads for JSArrayRef · 76a2ab06
      Jakob Gruber authored
      There are two aspects to the non-JSObject parts of JSArrayRef:
      
      - JSArrayRef::length. Relevant only in two spots, 1. when reading
      (immutable) array boilerplates and 2. for GetOwnCowElement.
      
      - JSArrayRef::GetOwnCowElement. May read into a copy-on-write backing
      store. Relies on the invariant that cow backing stores are immutable.
      
      This CL renames the length accessor to length_unsafe to make the
      danger explicit at callsites.
      
      For GetOwnCowElement the refactor is slightly larger, since we now
      need to read into the backing store while keeping full control of
      object reads (e.g. JSArray::length and JSArray::elements_kind). We
      make all reads explicit at the call site by requiring that elements,
      elements kind, and length are passed in as arguments to
      GetOwnCowElement. Inside GetOwnCowElement, consistency between these
      is *not* guaranteed due to concurrency. At runtime, consistency *is*
      guaranteed through the reference-equality check on the elements seen
      during compilation. The actual elements read is implemented in
      ConcurrentLookupIterator::GetOwnCowElement.
      
      Bug: v8:7790
      Change-Id: I9aa169ce4f2b1e2bfe1e9232007669eb7654a995
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695403
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72834}
      76a2ab06
  17. 16 Feb, 2021 1 commit
  18. 15 Feb, 2021 1 commit
  19. 12 Feb, 2021 1 commit
    • Georg Neis's avatar
      Reland "[compiler] Directly read PropertyCells" · cf7cba8d
      Georg Neis authored
      This reverts commit 87df0b7e (thus
      relands 42cd9eb7), with fixes for
      the discovered issues.
      
      Original change's description:
      > Revert "[compiler] Directly read PropertyCells"
      >
      > This reverts commit 42cd9eb7.
      >
      > Reason for revert: Clusterfuzz issues, e.g.
      > https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      >
      > Original change's description:
      > > [compiler] Directly read PropertyCells
      > >
      > > Main changes:
      > >
      > > - Introduce a new broker data kind kBackgroundSerialized for objects
      > >   that can be serialized in the background (when direct reads are on).
      > >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      > >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > > - Make PropertyCell use that new kind.
      > > - Introduce a bottleneck in runtime code for changes to PropertyCells
      > >   and make sure that a certain protocol is followed that allows
      > >   concurrent reads from the background thread.
      > > - Improve interface of PropertyCell in various ways.
      > >
      > > Bug: v8:7790
      > > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > > Commit-Queue: Georg Neis <neis@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#72586}
      >
      > TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      >
      > Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      > Bug: v8:7790
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72619}
      
      Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504
      Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72697}
      cf7cba8d
  20. 11 Feb, 2021 1 commit
  21. 10 Feb, 2021 1 commit
    • Georg Neis's avatar
      Revert "[compiler] Directly read PropertyCells" · 87df0b7e
      Georg Neis authored
      This reverts commit 42cd9eb7.
      
      Reason for revert: Clusterfuzz issues, e.g.
      https://bugs.chromium.org/p/chromium/issues/detail?id=1176318
      
      Original change's description:
      > [compiler] Directly read PropertyCells
      >
      > Main changes:
      >
      > - Introduce a new broker data kind kBackgroundSerialized for objects
      >   that can be serialized in the background (when direct reads are on).
      >   (I'm planning to remove kPossiblyBackgroundSerialized in a followup,
      >   in favor of a dynamic choice of kSerialized or kBackgroundSerialized).
      > - Make PropertyCell use that new kind.
      > - Introduce a bottleneck in runtime code for changes to PropertyCells
      >   and make sure that a certain protocol is followed that allows
      >   concurrent reads from the background thread.
      > - Improve interface of PropertyCell in various ways.
      >
      > Bug: v8:7790
      > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72586}
      
      TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org
      
      Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180
      Bug: v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72619}
      87df0b7e
  22. 09 Feb, 2021 1 commit
  23. 04 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [literals] Add a dedicated regexp boilerplate type · e79b841b
      Jakob Gruber authored
      ... and mark it as never-serialized wrt turbofan serialization.
      
      Until this CL, the JSRegExp type was used as both for plain
      user-visible regexp objects, and for internal regexp boilerplate
      descriptions. Boilerplates are special: they are never exposed to the
      user, they are only referenced from the feedback vector, they are
      immutable.
      
      To clarify this distinction, this CL introduces a dedicated struct
      type RegExpBoilerplateDescription to hold the regexp boilerplate
      description.
      
      This makes Turbofan serialization simpler: boilerplates can be
      accessed through direct reads since they are immutable. TF has no
      special requirements on JSRegExp objects (it never reads into these
      objects) and thus serializing only the references as a JSObjectRef is
      fine.
      
      Bug: v8:7790
      Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72522}
      e79b841b
  24. 22 Jan, 2021 1 commit
    • Victor Gomes's avatar
      [cleanup] Remove IrOpcode::kArgumentsFrame · f5eae65a
      Victor Gomes authored
      After removing the arguments adaptor frame, this should not be needed anymore.
      
      Removes ArgumentFrame from the following nodes:
      - ArgumentsLength
      - RestLength
      - NewArgumentsElements
      
      Also removes 'formal parameter count' as input of ArgumentsLength.
      
      Adapt the escape analysis to use the frame pointer directly instead of the ArgumentsFrame node.
      
      Change-Id: I0ead48a6ee05a10d05d6cfa2e46906ad69930986
      Bug: v8:11306
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639765
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72264}
      f5eae65a
  25. 21 Jan, 2021 1 commit
  26. 20 Jan, 2021 1 commit
  27. 03 Dec, 2020 1 commit
    • Leszek Swirski's avatar
      [compiler] Remove disallow scopes · a6f465d4
      Leszek Swirski authored
      TurboFan creates DisallowHeapAccess scopes, to prevent heap access in
      the concurrent parts of the compiler. Then, for parts of the compiler
      that do want to access the heap, it either creates Allow* scopes (which
      should be avoided since they "punch a hole" in the Disallow* scopes), or
      relies on a weakening of Handle::IsDereferenceAllowed which allows
      handles owned by a LocalHeap to be dereferenced even if there is a
      DisallowHeapDereference scope.
      
      This patch:
      
        a) Strengthens the implicit requirements around handle dereferencing
           to require a running heap on this thread (either main-thread heap
           or an un-parked, un-safepointed LocalHeap).
        b) Removes the overly strict Disallow scopes in TurboFan, relying
           instead on implicit requirements for allocation/handle
           dereferencing in off-thread code.
        c) Cleans up the "should_disallow_heap_access" predicate to be more
           explicit about what should be disallowed (e.g. property accesses
           can't be computed concurrently)
      
      Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71600}
      a6f465d4
  28. 13 Nov, 2020 1 commit
  29. 30 Oct, 2020 1 commit
  30. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  31. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      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}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  32. 24 Sep, 2020 1 commit
  33. 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
  34. 29 Jul, 2020 1 commit
  35. 16 Jul, 2020 2 commits
  36. 07 Jul, 2020 1 commit