1. 04 Oct, 2021 1 commit
  2. 30 Jun, 2021 1 commit
  3. 06 May, 2021 1 commit
  4. 05 May, 2021 1 commit
  5. 27 Jan, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Add more StartNode helpers · e75d8dbc
      Jakob Gruber authored
      Start nodes for JS functions have the following Parameter node value
      outputs:
      
       closure, ...args_including_receiver, new_target, argc, context
      
      This CL adds helper functions for these. There's two interesting
      gotcha's:
      
      - Each Parameter node is associated with an index, starting at -1.
      Value output indices obviously start at 0, so there's an off-by-one
      between the value output of the Parameter node, and the Parameter
      node's associated index.
      - CSA/Torque graphs use different Start node layouts, yet these are
      not reflected in compiler logic. There's potential for confusion here.
      The two layouts should be unified or made explicit.
      
      Finally, tests create Start nodes with arbitrary layouts. This blocks
      removal of methods marked _MaybeNonStandardLayout.
      
      In an ideal world, the parameter index would equal the start node
      output index, and the layout of all Start nodes would be equal. Future
      work..
      
      Change-Id: I908909880817979062d459b7a80ed4fede40e2ec
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649035
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72352}
      e75d8dbc
  6. 15 Jul, 2020 1 commit
  7. 18 Nov, 2019 1 commit
  8. 12 Sep, 2019 1 commit
  9. 05 Jul, 2019 1 commit
  10. 26 Jun, 2019 1 commit
    • Mike Stanton's avatar
      [TurboFan] Serializing context information · 386ff6e5
      Mike Stanton authored
      In TurboFan, context specialization is an optimization that tries to
      either replace the load of a value from the context with a constant,
      or if that can't be achieved, at least reduce the hops up the
      context chain by starting a walk to the required depth from the
      first constant context that it can reach.
      
      Currently, this optimization is performed by looking into the
      heap during a reducer pass. With fully concurrent TurboFan, we
      need to instead gather information about contexts we may want
      to perform this optimization on during serialization.
      
      This CL adds functionality to the serializer to recognize and
      model operations that affect the context register. We add to the
      hinting structure already used by the serializer. There is
      a new type of hint: a VirtualContext. This is a tuple consisting
      of a handle to a Context, and a distance field that indicates how
      far away in a to-be-realized chain this VirtualContext sits from
      the context in the handle. For example:
      
      bytecode stream:
      ...
      CreateBlockContext
      ...
      
      After a block context is created, the accumulator now contains
      a VirtualContext Hint with a distance of 1 from any context hints
      that we are keeping track of in the current context register.
      
      More details in the design doc here:
      https://docs.google.com/document/d/1Y0LKKCEenLWyAZTetoAIpKTZRCxaNdkYV8X1GaCax2A/edit?usp=sharing
      
      Change-Id: I63732ebd106cc138fb1e9789d0676ece63e15d27
      Bug: v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605941
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62370}
      386ff6e5
  11. 23 May, 2019 1 commit
  12. 21 Mar, 2019 1 commit
  13. 15 Oct, 2018 1 commit
  14. 18 Sep, 2018 1 commit
    • Georg Neis's avatar
      [turbofan] Get rid of HeapObjectType-related heap reads. · 253c2469
      Georg Neis authored
      This removes the last unconditional read accesses to the heap, but
      required a significant refactoring.
      
      - Remove HeapObjectRef::type().
      - Change HeapObjectData::Is* testers to look at the instance type
        in HeapObjectData::map().
      
      - Remove ObjectRef::oddball_type()
      - Add MapRef::oddball_type()
      - Add MapRef::is_undetectable().
      - Add MapRef::is_callable().
      
      - Remove JSHeapBroker::HeapObjectTypeFromMap()
      - Remove Type::For(JSHeapBroker*, Handle<Map>)
      - Add BitsetType::Lub(MapRef).
      - Add Type::For(MapRef).
      - Add Type::For(HeapObjectType).
      
      - Add HeapObjectRef::GetHeapObjectType(). THIS IS TEMPORARY.
      
      As the last item suggests, I couldn't actually remove the
      HeapObjectType class yet. See the explanation in the code.
      
      Bug: v8:7790
      Change-Id: I508e4bd5337277b0050f2204392fc36f41032fe9
      Reviewed-on: https://chromium-review.googlesource.com/1228033Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55994}
      253c2469
  15. 14 Sep, 2018 1 commit
  16. 16 Aug, 2018 1 commit
  17. 23 Jul, 2018 1 commit
  18. 17 Jul, 2018 1 commit
  19. 10 Jul, 2018 1 commit
  20. 26 Jun, 2018 1 commit
  21. 20 Jun, 2018 1 commit
  22. 18 Jun, 2018 1 commit
  23. 15 Jun, 2018 1 commit
  24. 05 Mar, 2018 2 commits
  25. 15 Dec, 2017 1 commit
    • Georg Neis's avatar
      [compiler] Don't assume a HeapConstant context input is a Context. · 649ab060
      Georg Neis authored
      In a generator containing loops, there are always certain control flow
      paths that are impossible, due to the way we represent generators at the
      bytecode level.  Unfortunately, the graph builder can't tell that these
      paths are impossible.  In combination with dead code, it can then happen
      that we build a subgraph (for unreachable code) whose incoming context
      is the undefined oddball.  JSContextSpecialization did not expect that.
      
      Bug: chromium:794822
      Change-Id: I259be5ae6c5f5adc8fca19c64bf71285ee922b7a
      Reviewed-on: https://chromium-review.googlesource.com/828954Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50129}
      649ab060
  26. 13 Sep, 2017 1 commit
  27. 07 Sep, 2017 1 commit
  28. 26 Jun, 2017 1 commit
  29. 04 May, 2017 1 commit
    • neis's avatar
      [compiler][modules] Constant-fold loads of module cells. · 24d78901
      neis authored
      1. Generalize context specialization such that the provided context
         can be any outer context of the function, not necessarily the
         immediate outer context.
      
      2. Based on this: if function specialization is disabled, then
         specialize for the module context if there is one.
      
      3. Extend typed lowering of module loads and stores such that if
         the operand is a Module constant, we constant-fold the cell load.
         That is, a JSLoadModule with a Module HeapConstant input becomes
         a LoadField with a Cell HeapConstant input, and similarly for
         JSStoreModule.
      
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2841613002
      Cr-Commit-Position: refs/heads/master@{#45083}
      24d78901
  30. 31 Mar, 2017 1 commit
  31. 13 Jan, 2017 1 commit
    • neis's avatar
      [compiler] Generalize JSContextSpecialization. · fd8cebb1
      neis authored
      With this CL, context loads and stores are "strengthened" by reducing
      the incoming context chain and decreasing the depth accordingly,
      whenever possible.  This enables more opportunities for specialization
      and will let us easily add module context specialization later.
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2559173003
      Cr-Commit-Position: refs/heads/master@{#42334}
      fd8cebb1
  32. 30 Nov, 2016 1 commit
  33. 06 Jun, 2016 1 commit
  34. 16 Dec, 2015 1 commit
  35. 18 Nov, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Decouple inlining and native context specialization. · 9b14e5bb
      bmeurer authored
      Retrieve the native context/global object from the Node being
      specialized in the JSNativeContextSpecialization and the
      JSGlobalObjectSpecialization classes. For this we introduce two
      new methods NodeProperties::GetSpecializationNativeContext and
      NodeProperties::GetSpecializationGlobalObject, which walk up
      the context chain and might in the end take the native context
      from the outermost activation (if native context specialization
      is enabled). This allows us to run the native context specialization
      pass as part of the inlining phase without hacking some of that into
      the JSInliner.
      
      Also refactor the NodeProperties::GetSpecializationContext method
      that was previously local to the JSContextSpecialization.
      
      Also refactor two other oddities in JSNativeContextSpecialization.
      
      R=jarin@chromium.org
      BUG=v8:4470, v8:4493
      LOG=n
      
      Review URL: https://codereview.chromium.org/1451143005
      
      Cr-Commit-Position: refs/heads/master@{#32076}
      9b14e5bb
  36. 07 Oct, 2015 3 commits
    • bmeurer's avatar
      [turbofan] Add initial support for global specialization. · e16dd13d
      bmeurer authored
      Introduce a new JSGlobalSpecialization advanced reducer that runs
      during the initial inlining and context specialization, and specializes
      the graph to the globals of the native context.  Currently we assume
      that we do not inline cross native context, but long-term we will grab
      the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
      new global load/store ICs that are currently in the workings), and then
      this whole specialization will be fully compositional even across
      cross-context inlining.
      
      Note that we cannot really handle most of the stores to global object
      property cells because TurboFan doesn't have a mechanism to enforce
      certain representations.  Also note that we cannot yet fully benefit
      from the type feedback collected on the global object property cells,
      because the type system cannot deal with maps in a reasonable way.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
      R=jarin@chromium.org
      BUG=v8:4470
      LOG=n
      
      Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
      Cr-Commit-Position: refs/heads/master@{#31139}
      
      Review URL: https://codereview.chromium.org/1387393002
      
      Cr-Commit-Position: refs/heads/master@{#31148}
      e16dd13d
    • bmeurer's avatar
      Revert of [turbofan] Add initial support for global specialization. (patchset... · 84065c5f
      bmeurer authored
      Revert of [turbofan] Add initial support for global specialization. (patchset #4 id:60001 of https://codereview.chromium.org/1387393002/ )
      
      Reason for revert:
      Breaks GC stress: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/1984/steps/Bisect%20c5528ac1.Retry/logs/regress-crbug-450960
      
      Original issue's description:
      > [turbofan] Add initial support for global specialization.
      >
      > Introduce a new JSGlobalSpecialization advanced reducer that runs
      > during the initial inlining and context specialization, and specializes
      > the graph to the globals of the native context.  Currently we assume
      > that we do not inline cross native context, but long-term we will grab
      > the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
      > new global load/store ICs that are currently in the workings), and then
      > this whole specialization will be fully compositional even across
      > cross-context inlining.
      >
      > Note that we cannot really handle most of the stores to global object
      > property cells because TurboFan doesn't have a mechanism to enforce
      > certain representations.  Also note that we cannot yet fully benefit
      > from the type feedback collected on the global object property cells,
      > because the type system cannot deal with maps in a reasonable way.
      >
      > CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
      > R=jarin@chromium.org
      > BUG=v8:4470
      > LOG=n
      >
      > Committed: https://crrev.com/6fbf7903f94924ea066af481719898bd9667b6eb
      > Cr-Commit-Position: refs/heads/master@{#31139}
      
      TBR=jarin@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4470
      
      Review URL: https://codereview.chromium.org/1390073004
      
      Cr-Commit-Position: refs/heads/master@{#31144}
      84065c5f
    • bmeurer's avatar
      [turbofan] Add initial support for global specialization. · 6fbf7903
      bmeurer authored
      Introduce a new JSGlobalSpecialization advanced reducer that runs
      during the initial inlining and context specialization, and specializes
      the graph to the globals of the native context.  Currently we assume
      that we do not inline cross native context, but long-term we will grab
      the global object from the JSLoadGlobal/JSStoreGlobal feedback (with the
      new global load/store ICs that are currently in the workings), and then
      this whole specialization will be fully compositional even across
      cross-context inlining.
      
      Note that we cannot really handle most of the stores to global object
      property cells because TurboFan doesn't have a mechanism to enforce
      certain representations.  Also note that we cannot yet fully benefit
      from the type feedback collected on the global object property cells,
      because the type system cannot deal with maps in a reasonable way.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel
      R=jarin@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1387393002
      
      Cr-Commit-Position: refs/heads/master@{#31139}
      6fbf7903
  37. 24 Sep, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Make Node::set_op safer via wrapper. · da9c42dd
      mstarzinger authored
      This introduces the NodeProperties::ChangeOp helper which guards node
      operator changes so that additional checking can be done without any
      additional dependencies being pulled into the Node class. For now only
      the input count is checked, but additional checking might follow.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1366753003
      
      Cr-Commit-Position: refs/heads/master@{#30916}
      da9c42dd