1. 02 Jun, 2020 4 commits
  2. 29 May, 2020 2 commits
  3. 28 May, 2020 3 commits
    • Ng Zhi An's avatar
      [wasm-simd] Prototype f32x4 rounding instructions · b7d14790
      Ng Zhi An authored
      Implements f32x4 ceil, floor, trunc, nearestint, for interpreter and
      x64.
      
      Bug: v8:10553
      Change-Id: Iab747cbd2a872aa6cd4ad23c5b8334d5c8e4da61
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2212435Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68054}
      b7d14790
    • Nico Hartmann's avatar
      Reland "[turbofan] Improve equality on NumberOrOddball" · 120d4333
      Nico Hartmann authored
      This is a reland of 6204768b
      
      The original issue exposed the problem that NumberEqual performs
      implicit conversion of oddballs to numbers, which is incorrect for
      abstract equality comparison (i.e. 0 == null must not be true).
      
      This reland fixes this by applying the following steps:
      * Introduced a new kNumberOrBoolean value for CompareOperationFeedback,
        CompareOperationHint, TypeCheckKind and CheckedTaggedInputMode.
      * In CodeStubAssembler::Equal: Further distinguish between boolean and
        non-boolean oddballs and set feedback accoringly.
      * In JSTypedLowering: Construct [Speculative]NumberEqual operator with
        CompareOperationHint::kNumberOrBoolean, when this feedback is present.
        JSOperatorBuilder and operator cache are extended accordingly.
      * In SimplifiedLowering: Propagate a UseInfo with new
        TypeCheckKind::kNumberOrBoolean.
      * This leads to the generation of CheckedTaggedToFloat64 in
        RepresentationChanger with new CheckedTaggedInputMode::kNumberOrBoolean.
      * In EffectControlLinearizer: Handle this new mode. Accept and convert
        number and boolean and deopt for rest.
      
      Original change's description:
      > [turbofan] Improve equality on NumberOrOddball
      >
      > This CL cleans up CompareOperationFeedback by replacing it with a
      > composable set of flags. The interpreter is changed to collect
      > more specific feedback for abstract equality, especially if oddballs
      > are involved.
      >
      > TurboFan is changed to construct SpeculativeNumberEqual operator
      > instead of the generic JSEqual in many more cases. This change has
      > shown a local speedup of a factor of 3-10, because the specific
      > operator is way faster than calling into the generic builtin, but
      > it also enables additional optimizations, further improving
      > runtime performance.
      >
      > Bug: v8:5660
      > Change-Id: I856752caa707e9a4f742c6e7a9c75552fb431d28
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162854
      > Reviewed-by: Mythri Alle <mythria@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67645}
      
      TBR: tebbi@chromium.org
      Bug: v8:5660
      Change-Id: I12e733149a1d2773cafb781a1d4b10aa1eb242a7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2193713
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68037}
      120d4333
    • Marja Hölttä's avatar
      [Promise.any] Make AggregateError.errors a data property · 0c44673a
      Marja Hölttä authored
      See https://github.com/tc39/proposal-promise-any/pull/64/
      
      Bug: v8:9808
      Change-Id: I5f11a5e306d17372ba7c24f313165de985444470
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2214826
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68034}
      0c44673a
  4. 27 May, 2020 7 commits
    • Ng Zhi An's avatar
      [wasm-simd][ia32] Fix all_true operand to be register · d4b58fec
      Ng Zhi An authored
      all_true uses pcmpeqd which takes a memory operand, but needs to be
      128-bit aligned, which we don't support yet.
      
      Bug: v8:9198
      Change-Id: Ia0caaaa76b1103ba538252181ef93e8557fb4739
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218887Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68027}
      d4b58fec
    • Milad Farazmand's avatar
      PPC/s390: [wasm-simd] Bitmask instructions · 4ea81214
      Milad Farazmand authored
      Port 043ac205
      
      Original Commit Message:
      
          Implement i8x16.bitmask, i16x8.bitmask, i32x4.bitmask on x64.
      
      R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I1bb6439abb3db27c50e1f06a833954c473119bcd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2219007Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#68023}
      4ea81214
    • George Wort's avatar
      [turbolizer] Display live ranges with sequences · 0282737d
      George Wort authored
      Display register allocation live ranges alongside sequences in
      turbolizer.
      
      The existing --trace-turbo flag now also outputs the register
      allocation data as part of the json file alongside the
      instruction sequence data that is already produced before and
      after register allocation is performed. This data includes live
      range intervals for each virtual and fixed register and the state
      of their assignments.
      
      This json data can now be displayed in turbolizer alongside the
      instruction sequences. The information is presented as a grid,
      with each grid cell representing a LifeTimePosition of a certain
      virtual register, determined by the column and row indices
      respectively. Each LifeTimePosition is shown to be part of an
      instruction id which itself is shown to be part of a block id.
      Each interval is shown as a coloured rectangle positioned over
      the relevant cells, and displaying text to indicate the state of
      their assignment.
      
      The Resizer object has been extended to allow the grid's html
      panel to be varied in size in the same manner that the left and
      right panels can be. The size of the grid itself must also be
      adjusted whenever the div container changes size.
      
      The RangeView class is introduced and is created and held by the
      single SequenceView object used to display the
      InstructionSequence data before and after register allocation.
      A checkbox allows the user to show/hide the range view, this is
      disabled when register allocation data is not provided or more
      than 249 instructions are in the sequence. The latter being
      required due to the css grid-row-col limit of 1000 alond with
      helping alleviate performance issues. The SequenceView object
      tracks the phase index currently selected as well as whether or
      not it is currently being shown. This ensures that the RangeView
      is not hidden and shown when switching between before and after
      register allocation, allowing for a smoother transition between
      the two. The scroll position is also saved and restored for
      convenience.
      
      The data about the instruction sequence required for the display
      is held by the RangeView object and reset whenever a new
      instruction sequence is shown. The grid div must sync its scroll
      with the headers and row labels so as to ensure a consistent
      view. The register allocation data is extracted from the json,
      with each register row showing all intervals within the relevant
      ranges. When the view is switched between before and after
      register allocation, the relevant intervals are swapped in.
      
      Bug: v8:7327
      Notry: true
      Change-Id: I183535a2410a7d663382f387199885250fb98691
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2184232Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68019}
      0282737d
    • Santiago Aboy Solanes's avatar
      [compiler] Have one traversal container for SimplifiedLowering's phases · 5602ce8b
      Santiago Aboy Solanes authored
      Since now all phases have the same order (or the reverse) we can share
      only one container that would specify the traversal order.
      
      We still need a queue that will be used for revisiting purposes in
      PROPAGATE and RETYPE.
      
      Bug: v8:10424
      Change-Id: Iab1e3c3cf6ffd342240d43be3b8ac77812aff211
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154201
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68008}
      5602ce8b
    • Santiago Aboy Solanes's avatar
      [compiler] Unify SimplifiedLowering's subphases traversal · 1ccb6d10
      Santiago Aboy Solanes authored
      We now have one initial phase (before PROPAGATE) that generates the
      traversal that the subphases are going to take. Generates post-order
      starting from End for RETYPE and LOWER, and the reverse for PROPAGATE.
      
      As a note, LOWER could use either PO or RPO.
      
      Bug: v8:10424
      Change-Id: I7435d681aba012b4f5e5ecd971bfa1d88bfb8b3a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154785Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68007}
      1ccb6d10
    • Jakob Gruber's avatar
      [compiler] Fix `slot` type for unary op builtins · 3ed3d9c8
      Jakob Gruber authored
      The `slot` parameter is expected to be a UintPtr.
      
      Bug: v8:8888
      Change-Id: Ia1137cd5af3d3aa0b00e9bf194661067c37332b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215047
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68005}
      3ed3d9c8
    • Manos Koukoutos's avatar
      [wasm-gc] Add packed types to ValueType · 782fa8d8
      Manos Koukoutos authored
      Motivation:
      In the wasm-gc proposal, structs and arrays are allowed to store
      elements of packed types i8 and i16.
      
      Changes:
      - Add i8 and i16 to ValueType.
      - Fix all case switches to handle the new cases.
      - Add a couple helper methods to ValueType and improve the
        implementation/usage of a couple more.
      
      Bug: v8:7748
      Change-Id: I527cfe5acf5d877fc38e4212174ba9f9de5c40ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2215046Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67994}
      782fa8d8
  5. 26 May, 2020 8 commits
  6. 25 May, 2020 2 commits
  7. 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
  8. 21 May, 2020 3 commits
    • Ng Zhi An's avatar
      [wasm-simd][arm] Improve f64x2 lt and le codegen · d48bbd52
      Ng Zhi An authored
      From 10 to 8 instructions (each). We do this by using mi (instead of lt)
      and ls (instead of le), which check for strictly less than and greater
      than or unordered. That way we don't have to have an extra mov for NaN.
      
      Change-Id: I18ff876ac12b7097d73d6cbbb64de6c2a1148e43
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2208934Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67947}
      d48bbd52
    • Ng Zhi An's avatar
      [wasm-simd] Rename anytrue and alltrue to follow proposal · 4c2f84b5
      Ng Zhi An authored
      The proposal uses the lane shape, e.g. i64x2.anytrue, and we were using
      s1x2.anytrue in our opcodes. This was a legacy naming, because we were
      trying to bitpack the booleans. Now that we aren't doing that, rename
      these to be more consistent with the proposal.
      
      This was done with a straightforward sed script, changing both cpp code
      and also some comments in mjsunit test files.
      
      Bug: v8:10506
      Change-Id: If077ed805de23520d8580d6b3b1906c80f67b94f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207915
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67945}
      4c2f84b5
    • Seth Brenith's avatar
      [diagnostics] Support --turbo-profiling for builtins · 18c73676
      Seth Brenith authored
      Currently, if d8 is run with the --turbo-profiling flag, it prints info
      about every TurboFan-compiled function. This info includes the number of
      times that each basic block in the function was run. It also includes
      text representations of the function's schedule and code, so that the
      person reading the output can associate counters with blocks of code.
      
      The data about each function is currently stored in a
      BasicBlockProfiler::Data instance, which is attached to a list owned by
      the singleton BasicBlockProfiler. Each Data contains an
      std::vector<uint32_t> which represents how many times each block in the
      function has executed. The generated code for each block uses a raw
      pointer into the storage of that vector to implement incrementing the
      counter.
      
      With this change, if you compile with v8_enable_builtins_profiling and
      then run with --turbo-profiling, d8 will print that same info about
      builtins too.
      
      In order to generate code that can survive being serialized to a
      snapshot and reloaded, this change uses counters in the JS heap instead
      of a std::vector outside the JS heap. The steps for instrumentation are
      as follows:
      
      1. Between scheduling and instruction selection, add code to increment
         the counter for each block. The counters array doesn't yet exist at
         this point, and allocation is disallowed, so at this point the code
         refers to a special marker value.
      2. During finalization of the code, allocate a BasicBlockProfilingData
         object on the JS heap containing data equivalent to what is stored in
         BasicBlockProfiler::Data. This includes a ByteArray that is big
         enough to store the counters for each block.
      3. Patch the reference in the BuiltinsConstantsTableBuilder so that
         instead of referring to the marker object, it now refers to this
         ByteArray. Also add the BasicBlockProfilingData object to a list that
         is attached to the heap roots so it can be easily accessed for
         printing.
      
      Because these steps include modifying the BuiltinsConstantsTableBuilder,
      this procedure is only applicable to builtins. Runtime-generated code
      still uses raw pointers into std::vector instances. In order to keep
      divergence between these code paths to a minimum, most work is done
      referring to instances of BasicBlockProfiler::Data (the C++ class), and
      functions are provided to copy back and forth between that type and
      BasicBlockProfilingData (the JS heap object).
      
      This change is intended only to make --turbo-profiling work consistently
      on more kinds of functions, but with some further work, this data could
      form the basis for:
      - code coverage info for fuzzers, and/or
      - hot-path info for profile-guided optimization.
      
      Bug: v8:10470, v8:9119
      Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67944}
      18c73676
  9. 20 May, 2020 1 commit
  10. 19 May, 2020 4 commits
  11. 18 May, 2020 5 commits
    • Ng Zhi An's avatar
      [wasm-simd][arm] Improve codegen for any_true · 9d1dda7e
      Ng Zhi An authored
      The codegen uses a bunch of vpmax to try and keep set bits around. The
      datatype for vpmax does not need to change for each instruction, since
      vpmax U32 will persist set bits just as well. This simplifies the
      instruction sequences for S1x8 and S1x16 anytrue.
      
      I added a test to check a special case when a f64x2 contains -0.0 (top
      bit set). A previous attempt to optimize codegen used floating point
      compare, which does not distinguish between 0.0 and -0.0. So -0.0 will
      compare equals to 0.0, and incorrect return 0 for anytrue.
      
      Change-Id: I66013796af08a666009e6b2d774ea7ee7bdfe1ad
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203113
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67875}
      9d1dda7e
    • Jakob Gruber's avatar
      Reland "[nci] Add Construct_WithFeedback builtin" · 7845967a
      Jakob Gruber authored
      This is a reland of 69f42d40
      
      Original change's description:
      > [nci] Add Construct_WithFeedback builtin
      >
      > This builtin essentially acts like InterpreterAssembler::Construct. It
      > collects full feedback, then tail-calls either the array constructor
      > or the construct builtin.
      >
      > For now, it is only used in generic lowering, if the --turbo-nci flag
      > is passed. One of the next steps will be to measure performance impact
      > of feedback collection. If minimal, we may want to enable it
      > unconditionally in generic lowering.
      >
      > Bug: v8:8888
      > Change-Id: I8a460a2b5954c26fa72658045a8423c5eee6b611
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198775
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67850}
      
      Tbr: neis@chromium.org
      Bug: v8:8888
      Change-Id: Ib1a81da998c848d63c0119b3a4e90fc917b15e94
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2206738
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67864}
      7845967a
    • Jakob Gruber's avatar
      Revert "[nci] Add Construct_WithFeedback builtin" · fe3e17d4
      Jakob Gruber authored
      This reverts commit 69f42d40.
      
      Reason for revert: The last PS introduced a bug https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20fyi/15897.
      
      Original change's description:
      > [nci] Add Construct_WithFeedback builtin
      > 
      > This builtin essentially acts like InterpreterAssembler::Construct. It
      > collects full feedback, then tail-calls either the array constructor
      > or the construct builtin.
      > 
      > For now, it is only used in generic lowering, if the --turbo-nci flag
      > is passed. One of the next steps will be to measure performance impact
      > of feedback collection. If minimal, we may want to enable it
      > unconditionally in generic lowering.
      > 
      > Bug: v8:8888
      > Change-Id: I8a460a2b5954c26fa72658045a8423c5eee6b611
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198775
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67850}
      
      TBR=neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I3af168373978d773385b9eda9bc1e243e3cbea09
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8888
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2206737Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67860}
      fe3e17d4
    • Clemens Backes's avatar
      [utils] Synchronize across StdoutStream instances · a0687c71
      Clemens Backes authored
      We constantly fight against scrambled output with --print-wasm-code and
      other flags. Passing --single-threaded only partially mitigates this,
      because there could still be multiple isolates (e.g. Workers), and we
      sometimes failed to really execute in a single thread if that flag was
      set.
      Hence this CL solves the problem in a more fundamental way: Whenever a
      {StdoutStream} is constructed, it implicitly takes a global recursive
      mutex. The recursive mutex is needed because we still have some printing
      methods that don't take a stream as parameter, and instead create their
      own instance of {StdoutStream}, which should not crash of course.
      
      The overhead of taking a mutex should be acceptable, since output to
      stdout mostly happens if special tracing flags have been passed, and is
      slow anyway.
      
      This CL ensures that the {StdoutStream} is used at least for
      --print-code, --print-wasm-code, and --trace-turbo-graph.
      More flags can later be ported on demand.
      
      The {JSHeapBroker} class was modified to not contain a {StdoutStream},
      but instead create one on demand.
      
      R=mlippautz@chromium.org, tebbi@chromium.org
      CC=ahaas@chromium.org
      
      Bug: v8:10506
      Change-Id: Ib9cf8d76aa79553b4215bb7775e6d47a8179aafa
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2201767Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67855}
      a0687c71
    • Jakob Gruber's avatar
      [nci] Add Construct_WithFeedback builtin · 69f42d40
      Jakob Gruber authored
      This builtin essentially acts like InterpreterAssembler::Construct. It
      collects full feedback, then tail-calls either the array constructor
      or the construct builtin.
      
      For now, it is only used in generic lowering, if the --turbo-nci flag
      is passed. One of the next steps will be to measure performance impact
      of feedback collection. If minimal, we may want to enable it
      unconditionally in generic lowering.
      
      Bug: v8:8888
      Change-Id: I8a460a2b5954c26fa72658045a8423c5eee6b611
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2198775
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67850}
      69f42d40