1. 19 Jul, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Make JSFunction bg-serialized · 0dba97f8
      Jakob Gruber authored
      This wraps up the transition away from kSerialized ref kinds.
      
      Since JSFunctionRef is a complex type, we don't attempt full
      consistency on the background thread. Instead, we serialize functions
      on the background in a partially-racy manner, in which consistency
      between different JSFunction fields is *not* guaranteed. Consistency
      is later verified through a new compilation dependency kind during
      finalization.
      
      Bug: v8:7790, v8:12004
      Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75789}
      0dba97f8
  2. 22 Oct, 2019 3 commits
    • Victor Gomes's avatar
      Reland x3 "[runtime] Remove extension slots from context objects" · dbbdd0ec
      Victor Gomes authored
      Original change's description:
      > [runtime] Remove extension slots from context objects
      >
      > Context objects have an extension slot, which contains further
      > additional data that depends on the type of the context.
      >
      > This CL removes the extension slot from contexts that don't need
      > them, hence reducing memory.
      >
      > The following contexts will still have an extension slot: native,
      > module, await, block and with contexts. See objects/contexts.h for
      > what the slot is used for.
      > The following contexts will not have an extension slot anymore (they
      > were not used before): script, catch and builtin contexts.
      > Eval and function contexts only have the extension slot if they
      > contain a sloppy eval.
      >
      > Bug: v8:9744
      > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64372}
      
      TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      
      Bug: v8:9744
      Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64477}
      dbbdd0ec
    • Clemens Backes's avatar
      Revert "Reland "Reland "[runtime] Remove extension slots from context objects""" · 725e7dd7
      Clemens Backes authored
      This reverts commit 392a1217.
      
      Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747
      
      Original change's description:
      > Reland "Reland "[runtime] Remove extension slots from context objects""
      > 
      > This is a reland of c48096d4
      > 
      > Original change's description:
      > > Reland "[runtime] Remove extension slots from context objects"
      > >
      > > This is a reland of c07c02e1
      > >
      > > Original change's description:
      > > > [runtime] Remove extension slots from context objects
      > > >
      > > > Context objects have an extension slot, which contains further
      > > > additional data that depends on the type of the context.
      > > >
      > > > This CL removes the extension slot from contexts that don't need
      > > > them, hence reducing memory.
      > > >
      > > > The following contexts will still have an extension slot: native,
      > > > module, await, block and with contexts. See objects/contexts.h for
      > > > what the slot is used for.
      > > > The following contexts will not have an extension slot anymore (they
      > > > were not used before): script, catch and builtin contexts.
      > > > Eval and function contexts only have the extension slot if they
      > > > contain a sloppy eval.
      > > >
      > > > Bug: v8:9744
      > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > > > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > > Cr-Commit-Position: refs/heads/master@{#64372}
      > >
      > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      > >
      > > Bug: v8:9744
      > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > Cr-Commit-Position: refs/heads/master@{#64380}
      > 
      > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      > 
      > Bug: v8:9744
      > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64451}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com
      
      Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9744
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64453}
      725e7dd7
    • Victor Gomes's avatar
      Reland "Reland "[runtime] Remove extension slots from context objects"" · 392a1217
      Victor Gomes authored
      This is a reland of c48096d4
      
      Original change's description:
      > Reland "[runtime] Remove extension slots from context objects"
      >
      > This is a reland of c07c02e1
      >
      > Original change's description:
      > > [runtime] Remove extension slots from context objects
      > >
      > > Context objects have an extension slot, which contains further
      > > additional data that depends on the type of the context.
      > >
      > > This CL removes the extension slot from contexts that don't need
      > > them, hence reducing memory.
      > >
      > > The following contexts will still have an extension slot: native,
      > > module, await, block and with contexts. See objects/contexts.h for
      > > what the slot is used for.
      > > The following contexts will not have an extension slot anymore (they
      > > were not used before): script, catch and builtin contexts.
      > > Eval and function contexts only have the extension slot if they
      > > contain a sloppy eval.
      > >
      > > Bug: v8:9744
      > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
      > > Commit-Queue: Victor Gomes <victorgomes@google.com>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > > Cr-Commit-Position: refs/heads/master@{#64372}
      >
      > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      >
      > Bug: v8:9744
      > Change-Id: I0749cc2d8f59940c25841736634a70047116d647
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      > Auto-Submit: Victor Gomes <victorgomes@google.com>
      > Cr-Commit-Position: refs/heads/master@{#64380}
      
      TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
      
      Bug: v8:9744
      Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@google.com>
      Cr-Commit-Position: refs/heads/master@{#64451}
      392a1217
  3. 24 May, 2019 1 commit
  4. 18 Apr, 2019 1 commit
  5. 19 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored
      This change significantly improves the performance of string
      concatenation in optimized code for the case where the resulting string
      is represented as a ConsString. On the relevant test cases we go from
      
        serializeNaive: 10762 ms.
        serializeClever: 7813 ms.
        serializeConcat: 10271 ms.
      
      to
      
        serializeNaive: 10278 ms.
        serializeClever: 5533 ms.
        serializeConcat: 10310 ms.
      
      which represents a 30% improvement on the "clever" benchmark, which
      tests specifically the ConsString creation performance.
      
      This was accomplished via a couple of different steps, which are briefly
      outlined here:
      
        1. The empty_string gets its own map, so that we can easily recognize
           and handle it appropriately in the TurboFan type system. This
           allows us to express (and assert) that the inputs to NewConsString
           are non-empty strings, making sure that TurboFan no longer creates
           "crippled ConsStrings" with empty left or right hand sides.
        2. Further split the existing String types in TurboFan to be able to
           distinguish between OneByte and TwoByte strings on the type system
           level. This allows us to avoid having to dynamically lookup the
           resulting ConsString map in case of ConsString creation (i.e. when
           we know that both input strings are OneByte strings or at least
           one of the input strings is TwoByte).
        3. We also introduced more finegrained feedback for the Add bytecode
           in the interpreter, having it collect feedback about ConsStrings,
           specifically ConsOneByteString and ConsTwoByteString. This feedback
           can be used by TurboFan to only inline the relevant code for what
           was seen so far. This allows us to remove the Octane/Splay specific
           magic in JSTypedLowering to detect ConsString creation, and instead
           purely rely on the feedback of what was seen so far (also making it
           possible to change the semantics of NewConsString to be a low-level
           operator, which is only introduced in SimplifiedLowering by looking
           at the input types of StringConcat).
        4. On top of the before mentioned type and interpreter changes we added
           new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
           CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
           checks.
      
      There are several more improvements that are possible based on this, but
      since the change was already quite big, we decided not to put everything
      into the first change, but do some follow up tweaks to the type system,
      and builtin optimizations later.
      
      Tbr: mstarzinger@chromium.org
      Bug: v8:8834, v8:8931, v8:8939, v8:8951
      Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
      Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
      Doc: https://bit.ly/fast-string-concatenation-in-javascript
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
  6. 02 Jan, 2019 1 commit
  7. 22 Nov, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Make typed optimization more powerful · 9b0e4e13
      Sigurd Schneider authored
      This CL moves optimization capabilities from typed lowering to typed
      optimization. In particular, this allows retyping of Speculative to
      number optimizations depending on their input types. This can save type
      checks if we know that inputs are already in SafeIntegerRange and uses
      are truncating to 32bit integers.
      
      This change recovers the performance lost to 31bit Smis on
      Octane/crypto on x64:
      32bit nosmis           avg 30,984.84 stddev 180.52
      31bit smis (w/o patch) avg 29,438.52 stddev 120.30  -4.99%
      31bit smis             avg 31,274.52 stddev 176.26  +0.93%  +6.24%
      
      Change-Id: I86d6e37305262336f4f7bd46aac0d2cbca11e8c1
      Bug: v8:8344
      Reviewed-on: https://chromium-review.googlesource.com/c/1323729
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57717}
      9b0e4e13
  8. 18 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Strength reduce JSResolvePromise to JSFulfillPromise. · 98aaeed6
      Benedikt Meurer authored
      We can strength-reduce JSResolvePromise(p,v) to JSFulfillPromise(p,v)
      if the v is known to be a primitive. This not only avoids the dynamic
      checks for v inside JSResolvePromise, but also removes the need to
      have a frame state, as the JSFulfillPromise operation cannot call
      back into arbitrary JavaScript, and thus cannot deoptimize lazily.
      
      This triggers for example for async functions where the return value
      is known (to TurboFan) to be a primitive value.
      
      Bug: v8:7253
      Change-Id: I4698d6026e0632ab3e2fef6c7f4aaacf6c2a508c
      Reviewed-on: https://chromium-review.googlesource.com/c/1288449
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56758}
      98aaeed6
  9. 15 Oct, 2018 1 commit
  10. 21 Sep, 2018 1 commit
  11. 17 Sep, 2018 1 commit
  12. 07 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a pure StringConcat operator. · e56b6d24
      Benedikt Meurer authored
      This replaces the previous CheckStringAdd operator which deopts in case
      the combined length overflows with a dedicated pure StringConcat operator.
      This operator is similar to NewConsString in that it takes the resulting
      length plus the two input strings. The operator relies on the length
      being checked explicitly by the surrounding code instead of baking the
      check into the operator itself. This way TurboFan can eliminate
      redundant/unnecessary StringConcat operations, since they are pure now.
      
      This also unifies the treatment of string addition in JSTypedLowering,
      and generalizes the StringLength constant-folding to apply to more cases
      not just the JSAdd cases inside JSTypedLowering.
      
      Bug: v8:7902, v8:8015
      Change-Id: I987ec39815a9464fd5fd9c4f7b26b709f94f2b3f
      Reviewed-on: https://chromium-review.googlesource.com/1213205Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55725}
      e56b6d24
  13. 30 Aug, 2018 1 commit
  14. 23 Jul, 2018 1 commit
  15. 12 Jul, 2018 1 commit
  16. 07 Jun, 2018 1 commit
  17. 28 Apr, 2018 1 commit
  18. 26 Apr, 2018 1 commit
  19. 24 Apr, 2018 1 commit
  20. 20 Feb, 2018 1 commit
  21. 24 Jan, 2018 1 commit
  22. 11 Jan, 2018 1 commit
  23. 30 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a dedicated StringLength operator. · 500d7b93
      Benedikt Meurer authored
      Strings are immutable in JavaScript land (contrast with the runtime,
      where we can truncate strings that haven't escaped to JavaScript yet),
      so the length of a String is immutable. Thus loading the length of a
      String is a pure operation and should be expressed as such (i.e. doesn't
      depend on control or effect). The StringLength operator does exactly
      this and is hooked up to the effect chain in the EffectControlLinearizer.
      
      This will eventually allow us to simplify the optimization of string
      concatention and other operations that are a bit cumbersome in TurboFan
      currently, and it will also allow us to optimize string operations
      across effectful operations, for example combining multiple invocations
      to String#slice with the same inputs.
      
      Bug: v8:5269, v8:6936, v8:7109, v8:7137
      Change-Id: Iffcccbb0c7fc4cfe1281c10e7af24b40eba4c987
      Reviewed-on: https://chromium-review.googlesource.com/799690Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49731}
      500d7b93
  24. 28 Nov, 2017 1 commit
  25. 21 Nov, 2017 3 commits
  26. 27 Oct, 2017 1 commit
  27. 19 Oct, 2017 1 commit
    • Mike Stanton's avatar
      [Turbofan] Model JSToBoolean as a simplified operator · 78fc6668
      Mike Stanton authored
      Because the toboolean operator may lower to a builtin call (which is
      effectful in turbofan parlance after effect control linearization),
      it really should be encoded as a simplified operator, which can
      be optimized with respect for the effect chain in linearization.
      
      No new functionality here, rather a furniture rearrangement in
      the TurboFan node structure.
      
      Bug: v8:6929
      Change-Id: I371fd22941397d5c28d13bded2738161d8da8275
      Reviewed-on: https://chromium-review.googlesource.com/725721Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48727}
      78fc6668
  28. 16 Oct, 2017 1 commit
    • Mike Stanton's avatar
      [TurboFan] Model TypeOf as a simplified operator · 9b2a8c22
      Mike Stanton authored
      Because the typeof operator may lower to a builtin call (which is
      effectful in turbofan parlance after effect control linearization),
      it really should be encoded as a simplified operator, which can
      be optimized with respect for the effect chain in linearization.
      
      No new functionality here, rather a furniture rearrangement in
      the TurboFan node structure.
      
      BUG=v8:6929
      
      Change-Id: I38593e10956ebd57cecdd606c35f3f73efb1327e
      Reviewed-on: https://chromium-review.googlesource.com/718745Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48613}
      9b2a8c22
  29. 01 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Optimize fast enum cache driven for..in. · f1ec44e2
      Benedikt Meurer authored
      This CL adds support to optimize for..in in fast enum-cache mode to the
      same degree that it was optimized in Crankshaft, without adding the same
      deoptimization loop that Crankshaft had with missing enum cache indices.
      That means code like
      
        for (var k in o) {
          var v = o[k];
          // ...
        }
      
      and code like
      
        for (var k in o) {
          if (Object.prototype.hasOwnProperty.call(o, k)) {
            var v = o[k];
            // ...
          }
        }
      
      which follows the https://eslint.org/docs/rules/guard-for-in linter
      rule, can now utilize the enum cache indices if o has only fast
      properties on the receiver, which speeds up the access o[k]
      significantly and reduces the pollution of the global megamorphic
      stub cache.
      
      For example the micro-benchmark in the tracking bug v8:6702 now runs
      faster than ever before:
      
       forIn: 1516 ms.
       forInHasOwnProperty: 1674 ms.
       forInHasOwnPropertySafe: 1595 ms.
       forInSum: 2051 ms.
       forInSumSafe: 2215 ms.
      
      Compared to numbers from V8 5.8 which is the last version running with
      Crankshaft
      
       forIn: 1641 ms.
       forInHasOwnProperty: 1719 ms.
       forInHasOwnPropertySafe: 1802 ms.
       forInSum: 2226 ms.
       forInSumSafe: 2409 ms.
      
      and V8 6.0 which is the current stable version with TurboFan:
      
       forIn: 1713 ms.
       forInHasOwnProperty: 5417 ms.
       forInHasOwnPropertySafe: 5324 ms.
       forInSum: 7556 ms.
       forInSumSafe: 11067 ms.
      
      It also improves the throughput on the string-fasta benchmark by
      around 7-10%, and there seems to be a ~5% improvement on the
      Speedometer/React benchmark locally.
      
      For this to work, the ForInPrepare bytecode was split into
      ForInEnumerate and ForInPrepare, which is very similar to how it was
      handled in Fullcodegen initially. In TurboFan we introduce a new
      operator LoadFieldByIndex that does the dynamic property load.
      
      This also removes the CheckMapValue operator again in favor of
      just using LoadField, ReferenceEqual and CheckIf, which work
      automatically with the EscapeAnalysis and the
      BranchConditionElimination.
      
      Bug: v8:6702
      Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
      Reviewed-on: https://chromium-review.googlesource.com/645949
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47768}
      f1ec44e2
  30. 28 Aug, 2017 1 commit
  31. 11 Aug, 2017 1 commit
  32. 10 Aug, 2017 1 commit
  33. 19 Jul, 2017 1 commit
  34. 11 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Enable reducers to report their name to make reducer tracing clearer · 7a75da34
      Alexandre Talon authored
      Each reducer now has a virtual reducer_name function, returning its name
      (the name of the class containing this reducer). This gets displayed when
      using the --trace_turbo_reduction flag. Also when using this flags more
      messages are displayed.
      
      Actually when a node is replaced in-place (which is called an update
      of the node), other reducers can still update it right after the
      in-place replacement. When a node is really replaced (not in-place),
      then we stop trying to apply reducers to it before we propagate the
      reduction through the relevant nodes.
      
      Before a message got printed only for the last reduction it went
      through. So in case a node was reduced in-place several times
      in a row, only the last update was printed, or none at all if after
      being reduced in-place it got reduced by being replaced by another
      node: only the non-in-place replacement was showed. 
      
      Now each time an in-place reduction is applied to a node, a message
      gets printed.
      
      Bug: 
      Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
      Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Cr-Commit-Position: refs/heads/master@{#46552}
      7a75da34
  35. 21 Jun, 2017 1 commit
  36. 19 Jun, 2017 1 commit