Skip to content

V
V8
Switch branch/tag
  1. 15 Oct, 2018 1 commit
  3. 11 Oct, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Implement implicit parameters · 9958694f
      Daniel Clifford authored 
      The implicit parameter syntax adds a second parameter list
before the explicit parameter list when declaring macros, builtins and
runtime functions:

  extern macro MyMacro(implicit a: Smi)(b: Oddball);

when calling the macro, only the formal parameters can be provided
at the call site. The implicit parameters are implicitly looked-up
by name in the scope of the call and prepended to the explicit parameter
list. The values that are found by name for each implicit parameter must
be castable the corresponding implicit parameter type:

  MyMacro(Null);  // Error, a is not defined
  ...
  const a: Smi = 0;
  MyMacro(Null);  // OK
  ...
  const a: Object = 0;
  MyMacro(Null);  // Error, a has wrong type

For external macros, builtins and runtime functions, the formal
parameter list expected on the C++ side is the concatenation of the
implicit and explicit parameter lists.

As a drive-by: fix the formatting of typeswitch statements in the
the presence of deferred-marked blocks and funky white space.

Bug: v8:7793
Change-Id: I40da8405c706d7cdeca35367c9c954d0b33f6bf4
Reviewed-on: https://chromium-review.googlesource.com/c/1270996
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56555}
      9958694f
  5. 08 Oct, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Allow atomarStatements in otherwise statements · 6f5600e2
      Daniel Clifford authored 
      In the process:
- Convert TryLabelStatements into TryLabelExpressions
- Change TryLabelExpressions to support only single label blocks and de-sugar
  try/labels into nested try/label statements. This allows the code in a label
  block to goto subsequent labels in the same try/label statement.
- Make otherwise expressions either take IdentifierExpressions which get
  converted into simple label names OR atomarStatements, which make useful
  non-label operations, like 'break' and 'continue', useful together with
  otherwise. Non-label otherwise statements get de-sugared into try/label
  blocks.

Bug: v8:7793
Change-Id: Ie56ede6306e2a3182f6aa1bb8750ed418bda01db
Reviewed-on: https://chromium-review.googlesource.com/c/1266997
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56447}
      6f5600e2
  7. 20 Sep, 2018 1 commit
  9. 18 Sep, 2018 1 commit
  11. 08 Aug, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] add typeswitch statement · 91ef86f9
      Tobias Tebbi authored 
      This adds a typeswitch statement

typeswitch (e)
case (x1 : Type1) {
  ...
} case (x2 : Type2) {

} ...
... case (xn : TypeN) {
  ...
}

This checks to which of the given types the result of evaluating e can
be cast, in the order in which they are listed. So if an earlier
type matches, a value of this type won't reach a later case.

The type-checks are performed by calling the cast<T>() macro.
The type of the argument passed to the cast macro is dependent on the
case and excludes all types checked earlier. For example, in

const x : Object = ...
typeswitch (x)
case (x : Smi) {
  ...
} case (x : HeapNumber) {
  ...
} case (x : HeapObject) {
  ...
}

there will be calls to cast<Smi>(Object) and
cast<HeapNumber>(HeapObject), because after the Smi check we know that
x has to be a HeapObject. With the refactored base.tq definition of
cast, this will generate efficient code and avoid repeating the Smi
check in the second case.

The type system ensures that all cases are reachable and that the type
given to the last case is safe without a runtime check (in other words,
the union of all checked types covers the type of e).

The cases can also be written as
case (Type) { ... }
, in which case the switched value is not re-bound with the checked
type.

Bug: v8:7793
Change-Id: Iea4aed7465d62b445e3ae0d33f52921912e095e3
Reviewed-on: https://chromium-review.googlesource.com/1156506
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54958}
      91ef86f9
  13. 27 Jul, 2018 2 commits
  15. 20 Jul, 2018 1 commit
  17. 17 Jul, 2018 2 commits
    • Daniel Clifford's avatar
      [torque]: Implement structs · 1062ffb9
      Daniel Clifford authored 
      Struct are bundles of value types. They are essentially just shorthand
for passing around a group of individually defined values.

Struct types are declared like this:

  struct A {
    x: Smi;
    y: int32;
  }

and can be constructed explicitly like this:

  A{0, 0}

Structs can be used wherever other types are used (e.g. variables,
parameters, return values) except for parameter/return types of
builtins and runtime functions.

Struct use field access notation to set/get their values like this:

  let a: A = A{0, 0};
  let b: Smi = a.x;
  a.y = 0;

Change-Id: I9fd36a6514c37882831256a49a50809c5db75b56
Reviewed-on: https://chromium-review.googlesource.com/1122133
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54501}
      1062ffb9
    • Simon Zünd's avatar
      [torque] Add local const bindings · b95def34
      Simon Zünd authored 
      This CL adds local const bindings. This means that instead of
generating TVARIABLEs for variables, we can generate simple TNodes.

Example:

macro FooBar(): {
  const kSomeSmi: Smi = 10;
  ...
}

This CL also enforces that variables with a constexpr type are bound
using 'const' and not 'let'.

R=tebbi@chromium.org

Bug: v8:7793
Change-Id: Id20a18149df9fc374ce718bdb1478e3eabb6e6df
Reviewed-on: https://chromium-review.googlesource.com/1138316
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54479}
      b95def34
  19. 13 Jul, 2018 1 commit
  21. 22 Jun, 2018 1 commit
  23. 12 Jun, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Turn implicit converts/unsafe_casts into generics · bbbfd81c
      Daniel Clifford authored 
      In the process:
  - Add strict ordering of Types so that name mangling is consistent
    and build time. Previously, the UnionType stored the union's
    types in a std::set<const Type*>, which did not have a consistent
    ordering of the types in the set.
  - Add a int31 type to enable consistency and correctness of
    handling of 'constexpr int31' values on the C++ side.
  - By removing the "implicit" keyword for operators, there is now
    one less difference between operators and calls, another
    incremental step in unifying operators and calls.
  - Enable external (i.e. C++-defined) generic specializations
  - Add CSA support for checking double ElementsKinds, including
    tests.
  - Clean up some constexpr/non-constexpr handling of ElementsKinds.

Bug: v8:7793
Change-Id: I27699aba70b98ebf5466e5b62b045d7b1dad62c8
Reviewed-on: https://chromium-review.googlesource.com/1091155
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53664}
      bbbfd81c
  25. 06 Jun, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Implement parameter overloading in generics · 06f2a5c2
      Daniel Clifford authored 
      This allows redifinitions of generics with the same name but differing parameter
type lists, e.g.

  macro coerce<Dest: type>(from: HeapObject): Dest;
  coerce<int32>(from: HeapObject): int32 {...}
  macro coerce<Dest: type>(from: Smi): Dest;
  coerce<int32>(from: Smi): int32 {...}

In order to allow multiple overloads of generic macros with the same name,
a more nuanced lookup of calls has been implemented using the
ParameterDifference utility class. There is still work to be done to unify
when ParameterDifference is used for lookup (e.g. removing it from operator
lookup when operators become simple aliases for macro names), but that work
will be done in a separate CL.

As part of this CL, the custom handling of "cast<>" operator in the .g4
grammar has been removed and replaced by a handful of equivalent overloads of
a generic "cast" macro.

Bug: v8:7793
Change-Id: Ibb2cdd3d58632b7f7f7ba683499f9688ae07f4f8
Reviewed-on: https://chromium-review.googlesource.com/1087873
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53562}
      06f2a5c2
  27. 04 Jun, 2018 1 commit
  29. 29 May, 2018 2 commits
    • Simon Zünd's avatar
      [torque] Add unsafe cast to Torque. · 9ef4df2f
      Simon Zünd authored 
      This CL is a proposal to add "checked" casts (CAST in CSA) to the Torque language.
The CL adds the "unsafe_cast<>" operator that emits a "CAST".

Example:

let n: Number = ...;
...
if (TaggedIsSmi(n)) {
  let m: Smi = unsafe_cast<Smi>(n);
  ...
}

The cast wont incur a runtime overhead now.

R=tebbi@chromium.org

Change-Id: I9fca90d1d11e61617ba0270e5022fd66200e2195
Reviewed-on: https://chromium-review.googlesource.com/1070151
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53416}
      9ef4df2f
    • Tobias Tebbi's avatar
      [torque] add union types · bf9d2893
      Tobias Tebbi authored 
      This adds support for union types to Torque.

There is a new type expression
A | B
to form the union of the type expressions A and B.
This is only possible if A and B have a common supertype, to prevent
nonsensical unions of types with different representations.

Union types are normalized:
A | B == B | A
A | (B | C) == (A | B) | C
A | A == A

The subtyping rules are defined recursively:
(A | B) <: C  if  A <: C and B <: C
A <: (B | C)  if  A <: B or A <: C

This allows to define Object as a union type:

type Tagged generates 'TNode<Object>';
type Smi extends Tagged generates 'TNode<Smi>';
type HeapObject extends Tagged generates 'TNode<HeapObject>';
type Object = Smi | HeapObject;

The type {Tagged} is introduced to have a common supertype of all
tagged values, but we should not use it directly, because {Object}
contains the additional information that there is nothing but {Smi}
and {HeapObject} values.

When mapping union types to CSA types, we select the most specific
common supertype. For Number and Numeric, we already use union types
on the CSA side. Since it is not possible to map to CSA union types
in general, we special-case these two union types to map them to
the CSA union types we already use.

Bug: v8:7793
Change-Id: I7a4e466436f55d04012f29ef17acfdb957653908
Reviewed-on: https://chromium-review.googlesource.com/1076132Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53411}
      bf9d2893
  31. 24 May, 2018 1 commit
  33. 22 May, 2018 3 commits
  35. 16 May, 2018 3 commits
  37. 04 May, 2018 2 commits
    • Daniel Clifford's avatar
      [torque]: Add constexpr keyword/types for compile-time evaluation · aeb86d57
      Daniel Clifford authored 
      Torque expressions of type constexpr are evaluated at compile-time
rather than runtime. They are backed by C++ types rather than
TNode<X> types, so the macro functions that are called by generated
C++ code expect values to be computed when the snapshot is generated
rather than by TurboFan-generated code.

Specifically, "if" statements can have a constexpr modifier. With this
modifier, a type of "constexpr bool" is expected rather than "bool",
and in that case instead of generating a CSA BranchIf, it generates
a C++ "if (<bool expression>)" that generates code for only the true or
false path based on the bool value at torque-execution (compile time)
rather than generating both paths (including inserting phi nodes
for variables modified on either branch at the re-merge at the end
of the if) and dynamically dispatching to the true or false path
during d8/Chrome/node.js execution (runtime) using a CSA BranchIf.

Change-Id: I8238e25aaadbfc618847e04556e96a3949ea5a8d
Reviewed-on: https://chromium-review.googlesource.com/1042085
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53001}
      aeb86d57
    • Daniel Clifford's avatar
      [Torque]: add assert(), unreachable and debug statements · 9cd8995f
      Daniel Clifford authored 
      - In debug builds, 'assert(<expr>)' evaluates and aborts execution
  if the provided Torque expression is false at runtime.
  assert(<expr>) supports the same set of expressions protocols
  as Toruqe's if statement, i.e. both bool values and BranchIf-
  style tests. Upon failure, the assertion prints the Torque
  source code of the failed expression, not the generated CSA
  code.
- 'unreachable' calls CSA's Unreachable() and signals to Torque
  that code execution cannot continue (i.e. its statement
  returns the 'never' type). In debug builds, the line number
  and position of the statement are printed before breaking.
- 'debug' calls CSA's DebugBreak(). In debug builds, the line
  number and position of the 'debug' are printed before breaking.

Change-Id: I4efd052536bb402c097a0d5f7be56e154b5b3676
Reviewed-on: https://chromium-review.googlesource.com/1042570
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52984}
      9cd8995f
  39. 03 May, 2018 1 commit
    • Daniel Clifford's avatar
      Refactor/cleanup various Torque classes, inclduing making Type a Declarable · 90415437
      Daniel Clifford authored 
      This is a preparatory step for implementing generics. Along the way, clean up
and encapsulate a bunch of code, including:

* Fully encapsulate Scope by adding the new class ScopeChain that provide an
  abstraction for creating and activating scopes.
* Untangle Modules and Scopes.
* Unify scope activation so that it is always associated with an AST node
  and triggered by a RAII helper class.
* Unify (somewhat) how builtins and macros are created, fixing a few
  inconsistencies with when and how parameters and their types are declared.
* Create a new Declarations class that brokers between the visitor classes and
  the ScopeChain. This moves handling of declaration-related errors out of the
  visitors but also makes it possible to do so without polluting Scope and
  ScopeChain with details about resolving SourcePositions in error cases.

Change-Id: I180017d4cf39ccf5ef1d20b84f53284c252f8d87
Reviewed-on: https://chromium-review.googlesource.com/1038504
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52947}
      90415437
  41. 24 Apr, 2018 1 commit
  43. 16 Apr, 2018 1 commit
    • Daniel Clifford's avatar
      Torque: Implement a DSL for CSA · a3353da8
      Daniel Clifford authored 
      An overview of motivation behind Torque and some of its principles
can be found here: https://bit.ly/2qAI5Ep

Note that there is quite a bit of work left to do in order to get
Torque production-ready for any non-trivial amount of code, but
landing the prototype as-is will allow for much faster iteration.

Bugs will be filed for all of the big-ticket items that are not
landing blockers but called out in this patch as important to fix.

Cq-Include-Trybots: luci.v8.try:v8_linux_nosnap_rel;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ib07af70966d5133dc57344928885478b9c6b8b73
Reviewed-on: https://chromium-review.googlesource.com/845682
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52618}
      a3353da8