1. 10 May, 2021 1 commit
  2. 11 Feb, 2021 1 commit
  3. 04 Dec, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] uniform flattening and string access in Torque · 65d2c4b4
      Tobias Tebbi authored
      Port String::Flatten to Torque (using a fast C call for the
      non-allocating part) and provide fast and easy access to sequential
      string data in Torque: GetStringData() flattens if necessary and
      computes slices that allow direct access.
      
      Applications: String.prototype.replaceAll, String.prototype.endsWith,
        and String.prototype.beginsWith now use GetStringData() and direct
        slice access instead of the slow StringCharCodeAt and they no
        longer bail out to the runtime for flattening.
      
      Drive-by changes:
        - Expose String instance type bits as bitfields and enums in Torque.
        - Fix method lookup in Torque to include superclass methods.
        - Use char8 and char16 types in more places.
        - Allow fast C calls with void return type.
        - Add Torque macros to create subslices.
        - Add no-GC scopes to runtime functions loading external string data.
      
      
      Bug: v8:7793
      Change-Id: I763b9b24212770307c9b2fe9f070f21f65d68d58
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565515
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71611}
      65d2c4b4
  4. 22 May, 2020 1 commit
    • Seth Brenith's avatar
      [torque] Generate better code when using `&` operator on bitfields · 98438d86
      Seth Brenith authored
      Sometimes CSA code carefully constructs a mask to check several
      bitfields at once. Thus far, such a check has been very awkward to write
      in Torque. This change adds a way to do so, using the
      non-short-circuiting binary `&` operator. So now you can write an
      expression that depends on several bitfields from a bitfield struct,
      like `x.a == 5 & x.b & !x.c & x.d == 2` (assuming b is a one-bit value),
      and it will be reduced to a single mask and equality check. To
      demonstrate a usage of this new reduction, this change ports the trivial
      macro IsSimpleObjectMap to Torque. I manually verified that the
      generated code for the builtin SetDataProperties, which uses that macro,
      is unchanged.
      
      Bug: v8:7793
      Change-Id: I4a23e0005d738a6699ea0f2a63f9fd67b01e7026
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183276
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67948}
      98438d86
  5. 10 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [torque] move more bitfield definitions to Torque · 87c16da5
      Seth Brenith authored
      This change moves the definitions of the bitfield flags used by Symbol
      and Map to Torque. Symbol could directly follow the pattern established
      by SharedFunctionInfo, but Map required some other changes:
      - Until now, Torque bitfield definitions have required unsigned types. I
        thought that this would be the least-surprising behavior, since we
        never sign-extend when decoding bitfield values. However, I believe
        that the amount of churn involved in making ElementsKind be unsigned
        outweighs the benefit we were getting from this restriction (and
        similar difficulties are likely to arise in converting other bitfield
        structs to Torque), so this CL updates Torque to allow signed bitfield
        values.
      - If we try to make Map extend from all of the generated classes that
        define its flags, we end up with class sizing problems because some
        compilers only apply empty base class optimization to the first in a
        row of empty base classes. We could work around this issue by
        generating macros instead of classes, but I took this as an
        opportunity for a minor clean-up instead: rather than having bitfield
        definitions for several different bitfield structs all jumbled
        together in Map, they can be split up. I think this makes the code a
        little easier to follow, but if others disagree I'm happy to implement
        macro generation instead.
      
      Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65701}
      87c16da5
  6. 16 Dec, 2019 1 commit
  7. 11 Nov, 2019 1 commit