1. 23 Feb, 2018 3 commits
  2. 04 Jan, 2018 1 commit
  3. 29 Nov, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Unify CanBePrimitive and NeedsConvertReceiver. · 9fb39c6b
      Benedikt Meurer authored
      The two helper functions CanBePrimitive and NeedsConvertReceiver did
      essentially the same, just in a slightly different way, and both weren't
      really robust wrt. to the list of JSConstruct* and JSCreate* operators
      that they were handling. There's now a single helper in the
      NodeProperties and a couple of extra macro lists to keep this list up
      to date more easily.
      
      Drive-by-fix: Also moved the CanBeNullOrUndefined helper to the
      NodeProperties class.
      
      Bug: v8:5267, v8:7109
      Change-Id: Ibbf387040e3f424ee224c53fac15c2b3207b1926
      Reviewed-on: https://chromium-review.googlesource.com/793734Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49695}
      9fb39c6b
  4. 27 Oct, 2017 1 commit
  5. 07 Sep, 2017 1 commit
  6. 31 Jul, 2017 1 commit
  7. 28 Jul, 2017 4 commits
  8. 10 Jul, 2017 1 commit
    • Jaroslav Sevcik's avatar
      Initial optimization of Map.prototype.(get|has) in Turbofan. · aba708a1
      Jaroslav Sevcik authored
      This introduces a new builtin (MapLookupHashIndex) and uses it
      in Turbofan to compute Map.p.get and Map.p.has.
      
      I have also refactored the existing CSA builtins for Map.p.get and 
      Map.p.has to use the new builtin under the hood.
      
      The code for the lookup has been also improved.
      - Specialized lookups for smis, strings, heap numbers and everything else.
        - the advantage is that we can use fast equalities for the lookup.
        - strings can likely be optimized further if we care about the 
          internalized string fast case.
      - Instead of a call to runtime to get the hash code, we now call C directly.
      
      In the Turbofan implementation itself, there are no special optimizations yet.
      The next step is to teach load elimination to reuse the indexes from
      previous calls of MapLookupHashIndex. 
      
      BUG=v8:6410
      
      Change-Id: I0b1a70493eb031d444e51002f6b2cc1f30ea2b68
      Reviewed-on: https://chromium-review.googlesource.com/560169Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46510}
      aba708a1
  9. 10 May, 2017 1 commit
  10. 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
  11. 12 Apr, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Use unreliable LOAD_IC feedback for Array.prototype.push. · 1fceaf9f
      bmeurer authored
      Add the notion of reliable vs. unreliable receiver map information to
      the NodeProperties::InferReceiverMaps machinery. The information is
      considered reliable here if the maps are known to be valid based on the
      effect chain, and unreliable if there was a side-effect in between that
      might have changed the receiver map.
      
      Use this unreliable information for Array.prototype.push, guarded by
      either stability dependencies or map checks, which might present a
      potential deoptimization loop, which is very unlikely, but still needs
      fixing in the future. This is important to optimize calls to push even
      in cases like this
      
        array.push(something.func());
      
      where we have a side-effect (the call to something.func) between the
      load of array.push and the actual call.
      
      R=jarin@chromium.org
      BUG=v8:5267,v8:6241
      
      Review-Url: https://codereview.chromium.org/2812233002
      Cr-Commit-Position: refs/heads/master@{#44595}
      1fceaf9f
  12. 02 Mar, 2017 1 commit
  13. 20 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Unify NodeProperties::InferReceiverMaps. · fc331225
      bmeurer authored
      Unify the three different implementations of InferReceiverMaps, which
      were basically copy&paste with slightly different optimizations applied
      later into a single NodeProperties::InferReceiverMaps helper, which also
      returns a ZoneHandleSet of maps, rather than only a single map.
      
      BUG=v8:5267
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2703133003
      Cr-Commit-Position: refs/heads/master@{#43318}
      fc331225
  14. 18 Jan, 2017 1 commit
  15. 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
  16. 17 Oct, 2016 1 commit
  17. 10 Oct, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Enforce native context specialization. · f6bd23f2
      bmeurer authored
      There were once plans to generate cross-context code with TurboFan,
      however that doesn't fit into the model anymore, and so all of this
      is essentially dead untested code (and thus most likely already broken
      in subtle ways). With this mode still in place it would also be a lot
      harder to make inlining based on SharedFunctionInfo work.
      
      BUG=v8:2206,v8:5499
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2406803002
      Cr-Commit-Position: refs/heads/master@{#40109}
      f6bd23f2
  18. 05 Sep, 2016 1 commit
  19. 03 Aug, 2016 1 commit
  20. 02 Jun, 2016 1 commit
  21. 25 Apr, 2016 1 commit
  22. 11 Jan, 2016 1 commit
  23. 20 Nov, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Initial support for Array constructor specialization. · aeb41de0
      bmeurer authored
      Introduce a JSCreateArray operator that represents the Array
      constructor, and lower call and construct calls to the Array
      constructor to JSCreateArray. Currently we don't yet replace
      that with an inline allocation, but always use the specialized
      stubs for the Array constructor.
      
      This saves a lot of unnecessary deopts and elements transitions
      because now we can actually consume the allocation site feedback
      for the transitions.
      
      R=mstarzinger@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1466643002
      
      Cr-Commit-Position: refs/heads/master@{#32145}
      aeb41de0
  24. 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
  25. 17 Nov, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Move JSCallFunction specialization to JSCallReducer. · e5edd66d
      bmeurer authored
      This is the first part to refactoring the JSNativeContextSpecialization
      class, which has grown way too big recently.
      
      Also don't collect cross context feedback for the CallIC in general.
      Neither TurboFan nor Crankshaft can make any use of cross context
      JSFunction feedback that is collected by the CallIC, so there's no
      point in gathering that feedback at all (it just complicates the
      checking that is necessary in the compilers). What we should do
      instead at some point (when Crankshaft becomes less important) is
      to collect the SharedFunctionInfo as feedback for those cases.
      
      R=yangguo@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1451273002
      
      Cr-Commit-Position: refs/heads/master@{#32022}
      e5edd66d
  26. 30 Oct, 2015 2 commits
    • bmeurer's avatar
      [turbofan] Add support for storing to double fields. · 0df0e254
      bmeurer authored
      Adds new Guard[Type] common operator, which takes value and control
      inputs and records a guaranty that a certain value has a certain type
      in that control path.  This is some kind of ad-hoc SSI similar to what
      we have to do in Crankshaft in some places.
      
      Also introduces an ObjectIsNumber simplified operator, which checks
      whether a certain value is a number (either a Smi or a HeapNumber).
      
      This doesn't yet support transitioning stores to double fields, which
      require support for allocating mutable heap numbers.
      
      R=jarin@chromium.org
      BUG=v8:4470
      LOG=n
      
      Review URL: https://codereview.chromium.org/1420283009
      
      Cr-Commit-Position: refs/heads/master@{#31675}
      0df0e254
    • bmeurer's avatar
      [turbofan] Fix missing bailout point before calls. · 6040d5c0
      bmeurer authored
      In order to properly (lazy) bailout when converting the receiver for
      sloppy mode functions (using the newly added JSConvertReceiver
      operator), we need to have a bailout location right before every call
      (also right before every %_Call and %_CallFunction), otherwise if the
      JSConvertReceiver just reuses the lazy bailout frame state from the
      JSCallFunction node, it will skip the whole function in case of lazy
      bailout.
      
      Note it should be impossible to trigger this currently because we do not
      yet support AllocationSite code dependencies in TurboFan, which can
      trigger this kind of lazy bailout; therefore it's not possible to write
      a regression test (yet).
      
      R=yangguo@chromium.org
      BUG=v8:4493
      LOG=n
      
      Review URL: https://codereview.chromium.org/1425883004
      
      Cr-Commit-Position: refs/heads/master@{#31668}
      6040d5c0
  27. 26 Oct, 2015 1 commit
    • bmeurer's avatar
      [turbofan] Sanitize typing rules for function calls. · 3fbbfc38
      bmeurer authored
      Currently we (mostly) infer FunctionType for JSFunction constants, and
      match the FunctionType in the typing rule for JSCallFunction. This has
      several drawbacks for JavaScript, especially we don't have Constant
      types for global functions (i.e. String, Object, Reflect and friends).
      Plus the FunctionType magic doesn't actually buy us anything. So this
      changes the typing rule for HeapConstant constant to actually infer
      Constant types for JSFunction objects and moves the recognition of
      builtin functions to the typing rule for JSCallFunction.
      
      Also adapts the specialized lowering in JSTypedLowering to Constant
      functions instead of FunctionType, which has the additional advantage
      that we can do the receiver wrapping/converting based on the (known)
      SharedFunctionInfo.
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1420093005
      
      Cr-Commit-Position: refs/heads/master@{#31553}
      3fbbfc38
  28. 15 Oct, 2015 1 commit
  29. 28 Sep, 2015 1 commit
  30. 25 Sep, 2015 1 commit
    • jarin's avatar
      [turbofan] Check node input/use consistency for changed operators and new nodes. · 1c2867c0
      jarin authored
      Verifies consistency of node inputs and uses:
      - node inputs should agree with the input count computed from the node's operator.
      - effect inputs should have effect outputs (or be a sentinel).
      - control inputs should have control outputs (or be a sentinel).
      - frame state inputs should be frame states (or be a sentinel).
      - if the node has control uses, it should produce control.
      - if the node has effect uses, it should produce effect.
      - if the node has frame state uses, it must be a frame state.
      
      I also removed some tests, either because they did not seem to be useful (scheduler) or they tested dead functionality (diamond effect phi).
      
      Review URL: https://codereview.chromium.org/1368913002
      
      Cr-Commit-Position: refs/heads/master@{#30927}
      1c2867c0
  31. 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
  32. 16 Sep, 2015 1 commit
  33. 10 Jun, 2015 1 commit
  34. 30 Apr, 2015 1 commit
    • svenpanne's avatar
      Detect simple tail calls · 4b122b75
      svenpanne authored
      This CL contains the first steps towards tail call optimization:
      
        * Structurally detect tail calls during instruction selection,
          looking for special return/call combinations.
      
        * Added new architecture-specific instructions for tail calls which
          jump instead of call and take care of frame adjustment.
      
        * Moved some code around.
      
      Currently we restrict tail calls to callees which only use registers
      for arguments/return value and to call sites which are explicitly
      marked as being OK for tail calls. This excludes, among other things,
      call sites in sloppy JS functions and our IC machinery (both need in
      general to be able to access the caller's frame).
      
      All this is behind a flag --turbo-tail-calls, which is currently off
      by default, so it can easily be toggled.
      
      Review URL: https://codereview.chromium.org/1108563002
      
      Cr-Commit-Position: refs/heads/master@{#28150}
      4b122b75