1. 29 Jan, 2019 1 commit
  2. 24 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque] Correctly support JSObject allocation with 'new' · 32a92cf5
      Daniel Clifford authored
      This requires honoring the instance size of the object stored in the
      map for JSObject. To do this, allocation is now split into two
      instrinsics, one that calculates the base size of the allocated object
      (%GetAllocationBaseSize) and one that actually allocates (%Allocate).
      
      In the process, remove objects.tq, which only existed to contain a
      macro to fetch the default JSObject map, which is functionality that
      is now in the JSObject class constructor.
      
      Bug: v8:7793
      Change-Id: I426a7943aac67eacad46d4ff39f5c821489a04bc
      Reviewed-on: https://chromium-review.googlesource.com/c/1426959
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59052}
      32a92cf5
  3. 22 Jan, 2019 3 commits
    • Daniel Clifford's avatar
      Reland "[torque] Implement safe initialization of classes through hidden structs" · 4c9bc648
      Daniel Clifford authored
      This is a reland of d11a0648
      
      Original change's description:
      > [torque] Implement safe initialization of classes through hidden structs
      > 
      > Initialization of classes now happens atomically at the end of the
      > class constructor only once all of the values for the class' fields
      > have been fully computed. This makes Torque constructors completely
      > GC safe, e.g. hardened against allocations or exceptions in
      > constructors.
      > 
      > As part of this change, make the 'this' parameter for method calls
      > explicit rather than implicit.
      > 
      > Drive by: add validation to check for duplicate field declarations
      > 
      > Bug: v8:7793
      > Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88
      > Reviewed-on: https://chromium-review.googlesource.com/c/1411252
      > Commit-Queue: Daniel Clifford <danno@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58979}
      
      Bug: v8:7793
      Change-Id: Ia8c23a36a661a73b5dc34437efd514a7c13a1ae8
      Reviewed-on: https://chromium-review.googlesource.com/c/1426840Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59005}
      4c9bc648
    • Daniel Clifford's avatar
      Revert "[torque] Implement safe initialization of classes through hidden structs" · 8c17e114
      Daniel Clifford authored
      This reverts commit d11a0648.
      
      Reason for revert: <INSERT REASONING HERE>
      
      Original change's description:
      > [torque] Implement safe initialization of classes through hidden structs
      > 
      > Initialization of classes now happens atomically at the end of the
      > class constructor only once all of the values for the class' fields
      > have been fully computed. This makes Torque constructors completely
      > GC safe, e.g. hardened against allocations or exceptions in
      > constructors.
      > 
      > As part of this change, make the 'this' parameter for method calls
      > explicit rather than implicit.
      > 
      > Drive by: add validation to check for duplicate field declarations
      > 
      > Bug: v8:7793
      > Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88
      > Reviewed-on: https://chromium-review.googlesource.com/c/1411252
      > Commit-Queue: Daniel Clifford <danno@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#58979}
      
      TBR=danno@chromium.org,tebbi@chromium.org
      
      Change-Id: Id6c46c175f53c5a77db1e6ca242586fba34cd02e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/1426121Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58980}
      8c17e114
    • Daniel Clifford's avatar
      [torque] Implement safe initialization of classes through hidden structs · d11a0648
      Daniel Clifford authored
      Initialization of classes now happens atomically at the end of the
      class constructor only once all of the values for the class' fields
      have been fully computed. This makes Torque constructors completely
      GC safe, e.g. hardened against allocations or exceptions in
      constructors.
      
      As part of this change, make the 'this' parameter for method calls
      explicit rather than implicit.
      
      Drive by: add validation to check for duplicate field declarations
      
      Bug: v8:7793
      Change-Id: I8b5e85980d6a103ef9fc3262b76f6514f36ebf88
      Reviewed-on: https://chromium-review.googlesource.com/c/1411252
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58979}
      d11a0648
  4. 17 Jan, 2019 1 commit
  5. 16 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque] Implement methods and constructors for structs and classes · b615dfa5
      Daniel Clifford authored
      With the changes in this patch,	it is now possible to add methods to
      both Torque's class and struct types. As a special case, "constructor"
      methods are used to initialize the values of classes and structs when
      they are constructed.
      
      The functionality in this patch	includes:
      
      - The refactoring of class- and struct-handling code to share field
        and method declaration code between both.
      
      - Addition of the "%Allocate" intrinsic that allocates raw bytes to be
        allocated from the V8 GC's NewSpace heap as the basis for freshly
        created, initialized class objects.
      
      - An implementation of a CallMethodExpression AST node that enables
        calling methods and constructors, including special handling of
        passing through the "this" pointer for method calls on structs by
        reference. The syntax for struct construction using "{}" remains as
        before, but now calls the struct's matching constructor rather than
        implicitly initializing the struct fields with the initialization
        arguments. A new syntax for allocation classes is introduced: "new
        ClassName{constructor_param1, constructor_param1, ...}", which
        de-sugars to an %Allocate call followed by a call to the matching
        constructor.
      
      - class	constructors can use the "super" keyword to initialize	their
        super class.
      
      - If classes and struct do not have a constructor, Torque creates a
        default constructor for them based on their field declarations,
        where each field's initial value is assigned to a same-typed
        parameter to the the default constructor. The default constructor's
        parameters are in field-declaration order, and for derived classes,
        the default constructor automatically uses a "super" initialization
        call to initialize inherited fields.
      
      - Class field declarations now automatically create ".field" and
        ".field=" operators that create CSA-compatible object accessors.
      
      - Addition of a no-argument constructor for JSArrays that creates an
        empty, PACKED_SMI_ELEMENTS JSArray using the machinery added
        elsewhere in this patch.
      
      Bug: v8:7793
      Change-Id: I31ce5f4b444656ab999555d780aeeba605666bfa
      Reviewed-on: https://chromium-review.googlesource.com/c/1392192
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58860}
      b615dfa5
  6. 10 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque]: Class declarations · d0e95c7a
      Daniel Clifford authored
      Class declarations support structured heap data that is a subtype of
      HeapObject. Only fields of Object subtypes (both strong and weak)
      are currently supported (no scalar fields yet).
      
      With this CL, both the field list macro used with the C++
      DEFINE_FIELD_OFFSET_CONSTANTS macro (to make field offset constants) as
      well as the Torque "operator '.field'" macros are generated for the
      classes declared in Torque. This is a first step to removing the
      substantial amount of duplication and boilerplate code
      needed to declare heap object classes.
      
      As a proof of concept, and handful of class field definitions,
      including those for non trivial classes like JSFunction, have been
      moved to Torque.
      
      Bug: v8:7793
      Change-Id: I2fa0b53db65fa6f5fe078fb94e1db3418f908753
      Reviewed-on: https://chromium-review.googlesource.com/c/1373971
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58704}
      d0e95c7a
  7. 17 Dec, 2018 2 commits
    • Jakob Gruber's avatar
      [nojit] Change builtin pointers to use Smis underneath · fa3cbf60
      Jakob Gruber authored
      This changes Torque's builtin pointers to use a Smi representation
      underneath instead of storing the Code target object. Callsites look
      up the target entry point through IsolateData::builtin_entry_table.
      
      The notable effect of this CL is that builtin pointer calls no longer
      call any on-heap Code.
      
      Bug: v8:7777
      Change-Id: Ibf6c749dd46cae7aba51494b09921229dd436f63
      Reviewed-on: https://chromium-review.googlesource.com/c/1379880
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58286}
      fa3cbf60
    • Jakob Gruber's avatar
      [nojit] Add a kCallBuiltinPointer call kind · f323a5f4
      Jakob Gruber authored
      Currently, Torque's builtin pointers store a Code target underneath and
      callsites generate a kArchCallCodeObject opcode. When embedded builtins
      are enabled, the call thus first calls the on-heap trampoline, which
      finally jumps to the target off-heap builtin code.
      
      This will no longer be possible in jitless mode, since on-heap code must
      not be executable.
      
      As a step towards changing the way builtin pointers are called
      (function pointers will hold the builtin index as a Smi, and callsites
      look up the off-heap target address and jump there), this CL adds a
      dedicated opcode for builtin pointer calls to the compiler pipeline.
      
      The calling mechanism itself is unchanged, changes there will happen
      in a follow-up.
      
      Drive-by: rename 'FunctionPointer' in torque/ to 'BuiltinPointer'.
      
      Bug: v8:7777
      Change-Id: Ic999a1cd7c3172425dd4a1513ae2f50c774faddb
      Reviewed-on: https://chromium-review.googlesource.com/c/1378175Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58281}
      f323a5f4
  8. 07 Dec, 2018 1 commit
  9. 05 Dec, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Add new and refine existing Torque intrinsic support · 79605b45
      Daniel Clifford authored
      Intrinsic changes:
      
      - Rename %RawCast to %RawObjectCast and add error checking so that it
        only applies to subtypes of Objects.
      
      - Add %RawPointerCast, which is similar to %RawObjectCast but must be
        used for all subtypes of RawPtr.
      
      - Add %RawConstexprCast, which allows one constexpr to be be cast to
        another at compile time. It translate to an appropriate static_cast
        in the generated code
      
      - Add %FromConstexpr, which handles most of the standard cases of
        generating XXXConstant CSA nodes from constexpr constants. It uses
        either SmiConstant, NumberConstant, StringConstant, IntPtrConstant
        or Int32Constant, depending on the cast-to type generic <To> type.
      
      - Add support for intrinsics that return constexpr results.
      
      Cleanup:
      
      - Turn FromConstexpr into a generic with two generic types, a <To> and
        a <From> type. Most FromConstexpr can use the new %FromConstexpr
        intrinsic rather than provide an explicit implementation.
      
      Bug: v8:7793
      Change-Id: Icab5db16d203034ec157fa3ad5157d10c7dc8464
      Reviewed-on: https://chromium-review.googlesource.com/c/1357049
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58049}
      79605b45
  10. 20 Nov, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] enable multiple inheritance from Torque-generated assemblers · 00ffe4a6
      Tobias Tebbi authored
      This enables more seamless interop between Torque and CSA:
      
      Since CodeStubAssembler can now inherit from the Torque base namespace,
      macros defined in the base namespace can be used in CodeStubAssembler
      macros, even without qualification.
      At the same time, macros in the base namespace can refer to
      CodeStubAssembler macros. The only new limitation is that types defined
      in code-stub-assembler.h cannot be referenced in the signature of macros
      defined in the base namespace, since this would produce a cyclic header
      dependency. A work-around for this woud be to put such types (like int31
      in this CL) into a separate header included by both. I (mis-)used
      code-assembler.h for that.
      Another side-effec is that types and enums defined in CodeStubAssembler
      have to be accessed in a qualified way from Torque.
      
      Other assemblers can now inherit from their Torque equivalent, so
      porting macros into the corresponding Torque namespace doesn't require
      any change to the existing use-sites.
      
      To avoid C++ ambiguities, the Torque-generated assemblers must not define
      anything also defined in Code(Stub)Assembler. This includes the type
      aliases for TNode, PLabel, ...
      My workaround is to qualify everything in the generated C++.
      
      As a drive-by fix, I had to change the formatter to avoid a situation
      where it doesn't compute a fixed point: putting a keyword at the
      beginning of a line removes the '\s' in front of it, so I replaced that
      with '\b'.
      
      Bug: v8:7793
      Change-Id: If3b9e9ad967a181b380a10d5673615606abd1041
      Reviewed-on: https://chromium-review.googlesource.com/c/1341955Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57645}
      00ffe4a6
  11. 13 Nov, 2018 1 commit
  12. 05 Nov, 2018 2 commits
    • Tobias Tebbi's avatar
      [torque] qualified access to CSA assemblers · 23b48920
      Tobias Tebbi authored
      No longer use inheritance to associate Torque-generated assemblers
      with corresponding CSA subclasses. Instead, all references to CSA
      and CSA-derived assemblers are now explicitly qualified, by generating
      a short-lived assembler instance in-place. As a consequence, Torque
      files have to mention the assembler external macros live in.
      The CodeStubAssembler is the default for this and can be omitted.
      As a drive-by cleanup, also distinguish between names that are emitted
      in C++ and names that are intended to be read in error messages. This
      is relevant for generic instantiations, where the generated names are
      rather unreadably mangled.
      
      As a follow-up, it will be easy to allow for qualified access to
      different modules, thus implementing full namespace semantics for
      modules.
      
      Bug: v8:7793
      Change-Id: Ie6f1b6b549b510fb49be2442393d898d5f130950
      Reviewed-on: https://chromium-review.googlesource.com/c/1309636
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57235}
      23b48920
    • Tobias Tebbi's avatar
      [torque] cleanup generics and scopes · 06c8ce59
      Tobias Tebbi authored
      - Name lookup in module scopes has namespace semantics now: All
        overloads from all parent modules are combined before overload
        resolution.
      - Allow overloads of different callables: runtime-functions,
        macros, builtins, and generics.
      - The duplication between the DeclarationVisitor and the
        ImplementationVisitor is removed: The DeclarationVisitor creates
        declarables for everything except for implicit generic specializations.
        The ImplementationVisitor iterates over declarables.
        The DeclarationVisitor only looks at the header of declarations, not
        at the body.
      - Modules become Declarable's, which will enable them to be nested.
      - Modules replace the existing Scope chain mechanism, which will make it
        easier to inline macros.
      - The DeclarationVisitor and Declarations become stateless. All state is
        moved to contextual variables and the GlobalContext.
      - Implicit specializations are created directly from the
        ImplementationVisitor. This will enable template parameter inference.
      - As a consequence, the list of all builtins is only available after the
        ImplementationVisitor has run. Thus GenerateBuiltinDefinitions has to
        move to the ImplementationVisitor. Also, this makes it necessary to
        resolve the link from function pointer types to example builtins only
        at this point.
      
      
      Bug: v8:7793
      Change-Id: I61cef2fd3e954ab148c252974344a6e38ee2d01d
      Reviewed-on: https://chromium-review.googlesource.com/c/1304294
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57231}
      06c8ce59
  13. 29 Oct, 2018 1 commit
  14. 15 Oct, 2018 1 commit
  15. 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
  16. 04 Oct, 2018 1 commit
  17. 18 Sep, 2018 1 commit
  18. 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
  19. 07 Aug, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] generate implicit_cast according to VisitResult types · 46952216
      Tobias Tebbi authored
      In the generated CSA, we called overloaded macros while relying on CSA
      subtyping of TNodes. This doesn't work well with overloads, because
      for C++ any TNode subtyping is treated as an implicit conversion, which
      makes these calls ambiguous for C++.
      As a solution, we insert implicit_cast conversions for arguments
      according to the type predicted by Torque. This way, a CSA overload is always
      called with exactly the signature declared in base.tq.
      This has the additional benefit that it validates the signatures declared in
      base.tq, which could previously be too permissive.
      Also, this triggered a bug in structs, where VisitResult's were
      carrying the wrong type.
      
      Bug: v8:7793
      TBR: danno@chromium.org
      Change-Id: I8ed4bfd04793c8a8805a4a3dd5cf2a85c20ce786
      Reviewed-on: https://chromium-review.googlesource.com/1165237
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54948}
      46952216
  20. 24 Jul, 2018 1 commit
  21. 17 Jul, 2018 1 commit
    • 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
  22. 13 Jul, 2018 1 commit
  23. 05 Jul, 2018 1 commit
    • Daniel Clifford's avatar
      [torque] Simplify handling of VisitResults · 1813e3d5
      Daniel Clifford authored
      Only pass around the unadulterated value identifier in the VisitResult class
      until the very last moment before code generation, at which point the
      declaration that was used to originally define the value is used to generate the
      correct final source code string in the context of a l-value or r-value.
      
      Bug: v8:7793
      Change-Id: Ifd0c0d245b2eb65c7f3ddb1ad4c87ee235c54a82
      Reviewed-on: https://chromium-review.googlesource.com/1125063
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54229}
      1813e3d5
  24. 03 Jul, 2018 1 commit
    • Tobias Tebbi's avatar
      [torque] fix variables, returns and conditionals with constexpr · 81186ff4
      Tobias Tebbi authored
      Variables/return values with constexpr type cannot have multiple
      assignments. We check this now.
      For conditionals, it is important to always infer a non-constexpr type.
      This CL adds the ability to map any type (including union types) to be
      mapped to their non-constexpr variant. Conditionals infer their type as
      the non-constexpr version of a combination of the two branch types.
      
      In addition, this improves subtyping for constexpr types:
      If A extends B, then constexpr A extends constexpr B.
      This makes it necessary to clean up "constexpr String", which has nothing
      to do with tagged values.
      
      Bug: v8:7793
      Change-Id: Ia4d3cd5dc98f45b0ec89adf05c5c6111a0e51cc6
      Reviewed-on: https://chromium-review.googlesource.com/1122864
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54167}
      81186ff4
  25. 26 Jun, 2018 1 commit
  26. 19 Jun, 2018 1 commit
  27. 15 Jun, 2018 1 commit
  28. 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
  29. 30 May, 2018 1 commit
  30. 29 May, 2018 2 commits
    • 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
    • Tobias Tebbi's avatar
      [cleanup] improve types in base.tq and use LoadTypedArrayLength everywhere · 54f77c42
      Tobias Tebbi authored
      Bug: v8:7754
      Change-Id: I8548d0e07fabc23bb5f65b1f91683c756195ae1b
      Reviewed-on: https://chromium-review.googlesource.com/1071654Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53398}
      54f77c42
  31. 22 May, 2018 1 commit
  32. 18 May, 2018 1 commit
  33. 16 May, 2018 1 commit
  34. 08 May, 2018 1 commit
  35. 04 May, 2018 1 commit
    • 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