Skip to content

V
V8
Switch branch/tag
  1. 06 Jul, 2021 1 commit
  3. 14 May, 2021 1 commit
    • Mike Stanton's avatar
      [compiler] Mark HeapNumberRef as never serialized · 9905c0b3
      Mike Stanton authored 
      This CL simplifies the approach to HeapNumbers in concurrent
compilation. We'll only create a HeapNumberRef for immutable
HeapNumbers -- this means that we don't need to validate the read
of the value with a compilation dependency check. Mutable
HeapNumbers are handled differently (the value is read for
constant folding, and protected with a constant field dependency).

This CL includes 2 reverts:
Revert "[compiler] Make HeapNumberRef background serialized"
Revert "[compiler] Fix endianness issue when reading HeapNumber"

Bug: v8:7790
Change-Id: I24e65583b787c214b917e96e789d711c2a7c9694
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891576
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74567}
      9905c0b3
  5. 10 May, 2021 1 commit
  7. 06 May, 2021 1 commit
  9. 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
  11. 11 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque][cleanup] Simplify some Torque-defined classes · e7693985
      Seth Brenith authored 
      This CL is pretty mechanical; I just iterated through some Torque
classes making the following changes:

- Use @generateCppClass if it seems easy to
- Use @generatePrint if the existing printer doesn't do anything special
- Fix up any imprecise field types

It also includes two minor changes to implementation-visitor:

- Add a new -inl.h file with the things needed for
  torque-generated/class-definitions-tq.cc so we don't need to keep
  changing the compiler when we add @generateCppClass.
- Avoid emitting incorrect accessors for ExternalPointers. This isn't
  strictly necessary for correctness, as the accessors defined in C++
  already hide the ones inherited from generated code, but it makes me
  feel safer.

Change-Id: I4d5a8ba6f86ebff57a0d147619212a3993b087c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2185824Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#67719}
      e7693985
  13. 11 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Generate instance types · 8c7ae314
      Seth Brenith authored 
      Design doc:
https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit

Changes from the design doc:
- Changed to use 'class' declarations rather than 'type' declarations
  for things that need instance types but whose layout is not known to
  Torque. These declarations end with a semicolon rather than having a
  full set of methods and fields surrounded by {}. If the class's name
  should not be treated as a class name in generated output (because
  it's actually a template, or doesn't exist at all), we use the
  standard 'generates' clause to declare the most appropriate C++ class.
- Removed @instanceTypeName.
- @highestInstanceType became @highestInstanceTypeWithinParentClassRange
  to indicate a semantic change: it no longer denotes the highest
  instance type globally, but only within the range of values for its
  immediate parent class. This lets us use it for Oddball, which is
  expected to be the highest primitive type.
- Added new abstract classes JSCustomElementsObject and JSSpecialObject
  to help with some range checks.
- Added @lowestInstanceTypeWithinParentClassRange so we can move the new
  classes JSCustomElementsObject and JSSpecialObject to the beginning of
  the JSObject range. This seems like the least-brittle way to establish
  ranges that also include JSProxy (and these ranges are verified with
  static assertions in instance-type.h).
- Renamed @instanceTypeValue to @apiExposedInstanceTypeValue.
- Renamed @instanceTypeFlags to @reserveBitsInInstanceType.

This change introduces the new annotations and adds the ability for
Torque to assign instance types that satisfy those annotations. Torque
now emits two new macros:
- TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the
  InstanceType enumeration
- TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String
  parts of INSTANCE_TYPE_LIST

The design document mentions a couple of other macro lists that could
easily be replaced, but I'd like to defer those to a subsequent checkin
because this one is already pretty large.

Bug: v8:7793
Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64258}
      8c7ae314
  15. 20 Aug, 2019 1 commit
  17. 21 Jun, 2019 1 commit
  19. 23 May, 2019 1 commit
  21. 21 May, 2019 2 commits
  23. 20 May, 2019 1 commit
  25. 15 Feb, 2019 1 commit
  27. 13 Feb, 2019 1 commit
  29. 09 Jan, 2019 1 commit
  31. 20 Dec, 2018 1 commit
  33. 18 Dec, 2018 1 commit
  35. 17 Dec, 2018 1 commit