1. 05 Feb, 2019 1 commit
  2. 04 Feb, 2019 1 commit
  3. 31 Jan, 2019 2 commits
  4. 29 Jan, 2019 1 commit
  5. 28 Jan, 2019 1 commit
    • Daniel Clifford's avatar
      [torque] Compile and error check all inlined macros · 7215f6d6
      Daniel Clifford authored
      Previously, macros that returned true for "ShouldBeInlined" were only
      compiled if they were called, which made it impossible to
      type/semantic check all Torque code (e.g. newly added methods to
      structs). One might argue that all code should be tested (and thus
      through inlining compiled), but for prototyping, the skipped
      compilations were definitely annoying.
      
      As part of this change, added a ShouldGenerateExternalCode method to
      declarables (by default returns !ShouldBeInlined) that makes it
      possible to suppresses C++ code generation for any method. To
      support this at the lowest level, a NullOStream classes is added as
      part of this patch.
      
      Finally, added support for generating C++ for passing structs as label
      parameters to run previously inlined methods through the
      implementation-visitor for non-inlined compilation.
      
      Bug: v8:7793
      Change-Id: I8ce23382e12ddc25f46222c25729c82433040a73
      Reviewed-on: https://chromium-review.googlesource.com/c/1434378
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59134}
      7215f6d6
  6. 25 Jan, 2019 2 commits
  7. 24 Jan, 2019 2 commits
  8. 23 Jan, 2019 1 commit
  9. 22 Jan, 2019 4 commits
  10. 17 Jan, 2019 2 commits
  11. 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
  12. 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
  13. 02 Jan, 2019 1 commit
  14. 18 Dec, 2018 1 commit
  15. 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
  16. 14 Dec, 2018 1 commit
    • Daniel Clifford's avatar
      [builtins] Port GetArgumentsFrameAndCount to Torque · a74afec6
      Daniel Clifford authored
      In the process, add the bint type (which stands for Best-INTeger),
      which implements Torque's idea of CSA's ParameterMode. It maps to
      a different type on 32-bit (Smi) and 64-bit (intptr). There are
      convert operators that are either no-ops or conversions
      to-and-from Smi and intptrs on the each platform, depending on
      the underlying type for bint. This allows Torque code to git most
      of the benefits of ParameterMode without having to explicitly
      pass around the mode, since it is almost always OptimalMode anyways.
      
      Change-Id: I92e08adc1d79cb3e24576c96f9734aec1af54162
      Reviewed-on: https://chromium-review.googlesource.com/c/1361160
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58253}
      a74afec6
  17. 07 Dec, 2018 1 commit
  18. 05 Dec, 2018 2 commits
    • Tobias Tebbi's avatar
      [torque] make C++ includes explicit · 82cf1cf2
      Tobias Tebbi authored
      Bug: v8:7793
      Change-Id: I12aae5d61a21f3e6e010e07622fe0d01a5ba03eb
      Reviewed-on: https://chromium-review.googlesource.com/c/1344118
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58052}
      82cf1cf2
    • 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
  19. 23 Nov, 2018 1 commit
  20. 22 Nov, 2018 2 commits
  21. 21 Nov, 2018 2 commits
  22. 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
  23. 19 Nov, 2018 1 commit
  24. 14 Nov, 2018 1 commit
  25. 13 Nov, 2018 3 commits
  26. 05 Nov, 2018 2 commits
    • Tobias Tebbi's avatar
      [torque] allow qualified access to different modules/namespaces · ece9156c
      Tobias Tebbi authored
      This introduces a new syntax for identifiers and calls: modulename::foo.
      Such a name is resolved by trying to find a module modulename in one of
      the parent scopes and looking for foo there. So this roughly corresponds
      to C++ qualified namespace lookup.
      
      Bug: v8:7793
      Change-Id: Iedc43e6ebe125cd74575cbbcbf990bbcc0155a1f
      Reviewed-on: https://chromium-review.googlesource.com/c/1309818
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDaniel Clifford <danno@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57238}
      ece9156c
    • 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